When you're developing new Transact-SQL code or modifying some existing code, do you just launch directly into programming?
I know that I did just that, for years. It wasn't until I was trying to performance tune some existing code that I realized I hadn't actually taken caching of data and execution plans into account. So all those modified stored procedures that I was so proud of might not actually be faster than the first generation of procedures because I hadn't checked to ensure that I was testing cached programs against uncached programs (and, by extension, the data used by those programs). That's easy enough to fix with a test harness. Test harness were originally an actual, physical harness used by engineers to clamp down parts of an electrical or mechanical device they were prototyping. Ours is no different. It locks down all of the assumptions about our code (like my early, false assumption that I didn't need to clear the caches) and adds a metric or two for good measure - literally - so we can better measure what's happening in that code.
Here's what my test harness looks like:
I also like to include the execution plans a lot of the time. You might wonder why I don't save the execution plans for the GUI in SSMS? Well, I'm a big advocate of scripting in general because I like to automate activities. By pulling the execution plans using scripts, I can use SQLCMD to schedule a large number of query executions during the evening and have the results ready for analysis when I come back into the office in the morning. Workin' smarter, not harder, Baby!
So how does this test harness work for you? Do you use other elements in yours? If so, share your experiences here!