SQL testing best practice

Question

Hi, What is the best practice for SQL testing (stored procedures, views, queries, triggers...) excluding automated testing? Most of the time a query works or returns thousands of rows, so it is a bit difficult to check them. I want to know how you usually do the testing of a SQL query. Can you point me to a good (online) reference?

Answer 1

Check out DBUnit.

Answer 2

Try to eliminate extra variables.

Ways to do this:

• Each test should test only one feature (a view, a stored procedure, etc.)
• Use known test data (it should be from a real environment (but not actually the real environment)
• Use the smallest amount of test data that adequately tests the feature.

Answer 3

This is not quite the same question but has many of the answers you are looking for. http://stackoverflow.com/questions/147362/what-is-the-best-way-to-test-a-stored-procedure

Answer 4

For inserts, updates, deletes I check the state of the table before and after the proc is run for records which meet the conditions of the inseret update or delete. So if I am adding 7 records, they shouldn't be in the table beforehand and should be there after.

Selects with thousands of records can be harder. There is no substitute for actaully knowing your data and what you would expect to get. For instance, I know that a certain client has around 2000 sales reps. If I run a query that should have all the reps on it, and there are only about 1000 of them, I know something is wrong. Sometimes I will place ther resutls of a query into a temp table, so I can run statistics on it. If I'm doing an attendee report I can then see that there are 200 distinct meetings in the report inthe time period according to my query. If I look at just that table and see there are 350 meetings in the same time period, I go looking to see what is excluding meetings and usually look at the details of one or more of the excluded meetings and it's related tables to see why it isn't showing up. Usually you will find a stauts that needs to accounted for or bad data of some sort.

I also look for record that are duplicated. If I expect one record per meeting and the same meeting is in there twice, I know that one of the join tables has more records than I was expecting for the conditions of the query.

I often ask some of our operations people to look at the results of a query for a report as well. Because they are closer to the use of the data than I am, they will often spot things I don't.

Another technique is to deliberately limit the where clasue for testing to a smaller subset of data that you can actually manaully examine to see if what you would expect is what you got. This is particularly helpful if you have lots of calculations or complex calulations. Anytime I do a complicated calculation I look at the raw data for one typical case and manually calculate the formula fromthe raw data, then I can check to see if it is correct in my query.

Triggers I test by writing them as regular queries first (after first creating and poplatung the temp tables for #inserted and #deleted). I make sure to add multiple records to my temp tables because every trigger must be able to correctly handle multiple record inserts/updates or deletes. THen I write code to show the before state and the after state and put it all in a transaction so I can roll it back while testing.