Timeline for Databases and Unit/Integration Testing
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 8, 2014 at 13:52 | comment | added | HLGEM | Again to re-iterate, you cannot unit test sql code agaist a blank database or opne with few records, you lose the meaning of the query and a query with correct syntax is irrelevant if it returns incorrect results. Ther result set is what you need to test not just the syntax. Unit testing for data is far differnt thatn application unit testing. | |
| Aug 15, 2011 at 22:04 | comment | added | HLGEM | No load testing is testing under the conditions of multiple users. But if you don;t test code against actual data how do you know your quereis return correct results? Syntax is easy to get running, correct results is what's hard. | |
| Aug 15, 2011 at 22:02 | comment | added | Nicholas Mayne | What you are actually talking about is load testing. If you had a set of Acceptence tests and hooked them in to a load testing tool you would then be able to achieve the desired effect. | |
| Aug 15, 2011 at 21:55 | comment | added | HLGEM | Strongly disagree. It's too late to find out that you have performance issues when you go to integration testing. | |
| Aug 15, 2011 at 21:45 | comment | added | Nicholas Mayne | Unit testing should never use a database - integration tests use databases. | |
| Aug 15, 2011 at 21:13 | comment | added | mmmmmm | Unit and integration tests are for functionality and not performance so you can test with small amounts of data | |
| Aug 15, 2011 at 20:45 | comment | added | HLGEM | Database queries are not just about the logical and the sooner you find out it won't work in prod the better. What works for 1 record often will timeout on prod and the unit test shoudl show that as soon as possible. | |
| Aug 15, 2011 at 20:42 | comment | added | ryanzec | I am not suggestioning running against an empty database, if you see step 2 I have "Then you insert all the data needed for the test cases you are about to run". About the performance issue, I don't think that is what unit testing is for, that is more load testing. Unit testing to me it to test to make sure the logical in your code work. if the logical works, it is going to work for 1 record or 100,000,000,000 records of the same basic data (thought it will be a lot slower). | |
| Aug 15, 2011 at 20:35 | history | answered | HLGEM | CC BY-SA 3.0 |