Unit testing certainly does give you the developer a warm fuzzy but that warm fuzzy can only get you so far. In the end you still have to make sure all your little pieces of code/functionality play nice together. This requires integration testing and if we are going to do any sort of testing that we actually expect to be performed on a regular basis we have to automate it. Automated integration testing often gets neglected and is substituted with manual testing, which delays finding issues and adds time to the project timeline. The reason that integration testing is often neglected is that it requires touching actual data.
Why is this is an issue:
All of this requires a lot of work, coordination…and a DBA [cringe]!
Let me introduce a scenario where all that is not required. Why can’t we wrap our tests in a Transaction?
Here’s what I am thinking:
Here is an example:
You can see that the first line of my test starts a transaction scope. I then create some data and add it to my empty database. Now, remember this database needs to be empty as to not mess up your expectations. After the data has been created I then perform the operation I am testing and assert the results.
You may be confused by the lack of a “Rollback” statement. The way TransactionScope works is that it only commits when explicitly told to do so.
Automated integration testing is a must have and in order to make your life easier follow the steps I have outlined and you will be free to live the TDD dream!
Keith is a Senior Software Engineer with Falafel Software. He has been developing software since 1999 specializing in web-based solutions primarily using the Microsoft stack. He has been a Microsoft MVP in ASP.NET since 2012.
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.