Unit testing isn't new. The idea of it isn't new. It can be difficult to decide what to test if you don't subscribe to the 100% code coverage methodology. Early in my career, no one let me near databases, so my understanding of them in the early years was extremely limited and even now is, as any DBA would say, crude at best. That crude understanding aside, I was recently asked about how to confirm that a column data type hasn't changed from a previous iteration.
Initially, I balked. If your column is supposed to be an int and your query returns "Donald Trump is a douche", then your database is seriously broken. While this initial reaction is correct, it doesn't prevent the database from getting broken, but there is a way to build and automatically use such tests in the Microsoft stack. MSDN contains a few articles on the subject. Click here for a quick primer.
You could test your objects, views, even and especially any stored procedures. This code should be tested just as any other code written should be tested. If you have that 100% code coverage rule, and you aren't writing SQL unit tests...well, you aren't meeting your own definition of done are you?
Initially, I balked. If your column is supposed to be an int and your query returns "Donald Trump is a douche", then your database is seriously broken. While this initial reaction is correct, it doesn't prevent the database from getting broken, but there is a way to build and automatically use such tests in the Microsoft stack. MSDN contains a few articles on the subject. Click here for a quick primer.
You could test your objects, views, even and especially any stored procedures. This code should be tested just as any other code written should be tested. If you have that 100% code coverage rule, and you aren't writing SQL unit tests...well, you aren't meeting your own definition of done are you?
