Comments on: Writing tests for stored procedures http://jonkruger.com/blog/2009/04/13/writing-tests-for-stored-procedures/ Fri, 18 May 2012 01:06:03 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Gary Woodfine http://jonkruger.com/blog/2009/04/13/writing-tests-for-stored-procedures/comment-page-1/#comment-5543 Gary Woodfine Mon, 07 Nov 2011 14:44:25 +0000 http://jonkruger.com/blog/?p=158#comment-5543 If you check out the Visual Studio Premium edition, there is the "Data Dude" feature, AKA Database edition . Within in that there is the capability of database unit tests. http://msdn.microsoft.com/en-us/library/bb381703(v=vs.80).aspx . If you check out the Visual Studio Premium edition, there is the “Data Dude” feature, AKA Database edition . Within in that there is the capability of database unit tests. http://msdn.microsoft.com/en-us/library/bb381703(v=vs.80).aspx .

]]> By: DotNetKicks.com http://jonkruger.com/blog/2009/04/13/writing-tests-for-stored-procedures/comment-page-1/#comment-3729 DotNetKicks.com Tue, 14 Apr 2009 01:29:04 +0000 http://jonkruger.com/blog/?p=158#comment-3729 <strong>Writing tests for stored procedures...</strong> You've been kicked (a good thing) - Trackback from DotNetKicks.com... Writing tests for stored procedures…

You’ve been kicked (a good thing) - Trackback from DotNetKicks.com…

]]> By: Jon Kruger http://jonkruger.com/blog/2009/04/13/writing-tests-for-stored-procedures/comment-page-1/#comment-3724 Jon Kruger Mon, 13 Apr 2009 19:42:14 +0000 http://jonkruger.com/blog/?p=158#comment-3724 You could do something similar with the test dataset and accomplish the same thing, but in my experience when I do it that way, I'm constantly breaking the tests because of something changing in the database because my tests are dependent on so many different things. But you're right, for really complicated procs, data conversions, etc., this is probably the best way. I'd have to disagree with you on simpler procs. I wrote tests like this on my project last year, and I'm glad I did because the procs I was testing were inserting ~2000 rows of production data and adding a lot more from inside triggers. I wouldn't want to do that without tests because if I screw it up, it's really really hard to fix (we actually did have a problem in that situation because I didn't have all the requirements, so I spent a day cleaning up bad data). Plus, after I left that project they had to change those sprocs again so I'm sure they were glad they had automated testing that told that they didn't break everything. Dealing with all of the stored procs on that project was a real pain. It wasn't that they were written poorly (some of them were, but most seemed alright to me), but you never knew everything that they were supposed to do or if you were breaking something. If they had automated tests written, I would've known right away what they were supposed to do and if I was breaking them. To me, that is invaluable, especially since we are constantly coming into projects and leaving them soon after. You could do something similar with the test dataset and accomplish the same thing, but in my experience when I do it that way, I’m constantly breaking the tests because of something changing in the database because my tests are dependent on so many different things. But you’re right, for really complicated procs, data conversions, etc., this is probably the best way.

I’d have to disagree with you on simpler procs. I wrote tests like this on my project last year, and I’m glad I did because the procs I was testing were inserting ~2000 rows of production data and adding a lot more from inside triggers. I wouldn’t want to do that without tests because if I screw it up, it’s really really hard to fix (we actually did have a problem in that situation because I didn’t have all the requirements, so I spent a day cleaning up bad data). Plus, after I left that project they had to change those sprocs again so I’m sure they were glad they had automated testing that told that they didn’t break everything.

Dealing with all of the stored procs on that project was a real pain. It wasn’t that they were written poorly (some of them were, but most seemed alright to me), but you never knew everything that they were supposed to do or if you were breaking something. If they had automated tests written, I would’ve known right away what they were supposed to do and if I was breaking them. To me, that is invaluable, especially since we are constantly coming into projects and leaving them soon after.

]]> By: sqlblindman http://jonkruger.com/blog/2009/04/13/writing-tests-for-stored-procedures/comment-page-1/#comment-3723 sqlblindman Mon, 13 Apr 2009 19:29:25 +0000 http://jonkruger.com/blog/?p=158#comment-3723 Jon, you have a 50 line test script for a 10 line piece of code. I understand that this may give you piece of mind, but the logic of your test process is an order of magnitude more complex than the logic in your procedure. So where are errors most likely to occur, where is most of the adminstrative overhead likely to occur during refactoring and feature enhancement? And your sproc was extremely simple, pulling from only one table. Many sprocs are EXTREMELY complex and involve multiple levels of conditional logic, perhaps based upon aggregations of data from half a dozen tables or more. The script to create such test data would be enormous, and would have to ensure that all the test data meets relational integrity requirements and does not violate constraints. In your example, for instance, what happens if there is a unique constraint on Username (there should be) and the username 'test' already exists? While the example you cited is not outrageously impractical, though of correspondingly lesser value due to the simplicity of the tested code, trying to implement this approach on a 500 line piece of SQL that runs against a self-referencing normalized tables would be quite a challenge. I think the best way to handle this is to have a stable test dataset already in place, that is migrated along with any scripts applied to production. A test harness for a sproc would then need only run the sproc with preset values and verify the results. Jon, you have a 50 line test script for a 10 line piece of code.
I understand that this may give you piece of mind, but the logic of your test process is an order of magnitude more complex than the logic in your procedure. So where are errors most likely to occur, where is most of the adminstrative overhead likely to occur during refactoring and feature enhancement?
And your sproc was extremely simple, pulling from only one table. Many sprocs are EXTREMELY complex and involve multiple levels of conditional logic, perhaps based upon aggregations of data from half a dozen tables or more. The script to create such test data would be enormous, and would have to ensure that all the test data meets relational integrity requirements and does not violate constraints. In your example, for instance, what happens if there is a unique constraint on Username (there should be) and the username ‘test’ already exists?
While the example you cited is not outrageously impractical, though of correspondingly lesser value due to the simplicity of the tested code, trying to implement this approach on a 500 line piece of SQL that runs against a self-referencing normalized tables would be quite a challenge.
I think the best way to handle this is to have a stable test dataset already in place, that is migrated along with any scripts applied to production. A test harness for a sproc would then need only run the sproc with preset values and verify the results.

]]>