Sorry I didn't get back to you sooner, but I didn't get any alerts that there were posts on this article. I thought no one was reading it.
Several of us here have read your article and we used it as a template to get started. Thanks for your work.
Sorry I was unclear in the article. Yes, we're generating the templates, but not completely eliminating the need for a developer to build out an expected result set. It's just not something we've been able to come up with any method of automating. The main thing the generation does for us is eliminate a ton of typing since we build out the variable declaration and query execution, etc..
We built a query that compares two sets of data by simply doing a count of the table and a count of the union. If they're different, it fails the test. Simplistic and limited it may be, but it gets the job done. We had tried exporting data to XML & doing all kinds of other comparisons, but this simple approach seemed to work much better than the fancier ones.
So, the developers have to generate an expected test data set, run the proc to get the actual data set and run these into the assert proc to determine if they're the same.
Hopefully that sheds a bit more light on the matter. Sorry again for the lack of clarity. Thanks again for your article, it was a big help to get us started.
The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood...
Theodore RooseveltThe Scary DBA
Author of: SQL Server Query Performance Tuning
and SQL Server Execution Plans
Product Evangelist for Red Gate Software