One problem we often have when performing application test is that if we are testing applications that modify the database in some way, we can’t test without modifying the database.
In an ideal world, one way you could deal with this issue is to create a test database that has known data. But even then, you have to go through the effort of setting up the data prior to each test.
To be clear, I’m not talking about unit test. You should have unit test for most of your code. I’ll handle what not to test in some other post. But, at some point you will want to put together a suite of test that ensures that the application, as a whole, does what you expect it to do.
So, the stated problem is this, “How do we test a web application in such a way that we are always working with known data and in such a way that we do not ever modify the data in the database?”
So far, I’ve not found a way that test the whole web application from the user interface down to the database. But, I think I’ve found the next best thing. Split the application in half between the view and the database and perform two, overlapping, integration test. If both work, we can reasonably assume that the whole application works.
So how would we go about doing this?
If you’ve designed your application correctly, you should have a seam somewhere in the center. In my code it tends to either be at the business logic layer or at the data access layer. What we want to do is to create a separate class, or set of classes that look just like the classes at that layer and swap them in while testing the top half of our application and use the real classes when testing the bottom half of the application and when using the application in production.
We do this using dependency injection using your favorite dependency injection framework. I’m not going to go into the details of dependency injection here. Maybe some other day. But this is a place where you would use it.
Test the top half
In the fake DAL or BLL classes, what you are going to do is return what amounts to hard coded values. In a recent implementation, I stored the JSON representation of the values in a resource (RESX) file using the parameters that were passed into the method call as keys so that I could retrieve that data. If you need to do an update, you will need to store that some place so that your test code can verify that it got passed down to the function that should have saved it to the database.
By doing this, you can verify that your code from the presentation layer down to this seam works as it should. Now we need to test the bottom half of our code.
Test the bottom half
This will be a bit easier. What we do here is we have our test code run the code directly. But, unlike when we run the code in production, we will wrap the code in transaction tracking starting with our setup method. We turn on transaction tracking, get the database into the state that we need for testing, run our test, and then rollback the changes. Assuming the transaction tracking works correctly, and we have to assume that our third party tools do, this test everything without modifying the database.
Because we’ve tested both the top half of the code and the bottom half of the code, we now have a reasonable assurance that the code as a whole works as it should.
Other post in TDD
- Why Don't You Practice Test First Development? - February 20th, 2014
- Test Driven Specifications - February 25th, 2014
- Unit Test Structure - March 11th, 2014
- When You Really Need All Of Your NUnit Test In One Class - March 18th, 2014
- TDD Isn’t All About Testing - March 25th, 2014
- Automated Web Application Functional Testing - April 1st, 2014
- What Not To Test - April 9th, 2014
- Make Your Test Work For You - April 18th, 2014
- Don’t Comment Out That Test - April 24th, 2014
- The Proper Function of QA - May 1st, 2014
- TDD Saves Time – A Story - May 22nd, 2014
- It is called "Unit Testing" for a reason - August 28th, 2014
- Is Your Architecture Crippling Your Unit Testing? - September 4th, 2014
- Selenium Performance Improvements - October 2nd, 2014
- Technical Debt Is Inevitable - October 16th, 2014
- NUnit, Unity Dependency Injection, MOQ and Private Fields - October 23rd, 2014
- NUnit & Visual Studio - December 4th, 2014
- Software Architecture without Test Driven Development is DANGEROUS! - January 29th, 2015
- NUnit Test Code Structure - February 5th, 2015
- Excuses For Not Testing - February 26th, 2015
- Why Johnny Can't do Test Driven Development - March 5th, 2015
- Changing Habits - March 19th, 2015
- 100% Code Coverage Possible? - March 26th, 2015
- TDD Gamification - Turning Test Driven Development into a Game - April 23rd, 2015
- Run NUnit from Visual Studio - April 30th, 2015
- The Parable of The Road Line Painter - May 28th, 2015
- The Fallacy of Motion - July 23rd, 2015
- Test Driven Learning - An Experiment - March 24th, 2016
- 3 Reasons You Believe 100% Code Coverage Is Impossible - May 26th, 2016