SDNET – all about .NET and computing

One of the challenges of today’s projects is automatic tests. When we speak of automated testing we always target repeatability, meaning what we test today we must be able to test tomorrow and later. This is easy for database independent applications but when your testing functionality that modifies data you always find yourself wondering how can you ensure that when the tests start you have correct data.

Just to exemplify we will give an example. Suppose you have a table User with fields Id and Name. Your functionality needs to make an insert into this table but only if a user with the same name does not exist. You make an NUnit that tests the insert, when the tests runs a new user is inserted. But what happens when you run the second time the test? Well the insert will not execute as the user already exists. To avoid this situations you have 3 choices:

• run a script at the end of the test that will clean up any existing data (you can do this also at the begining of the test). The main problem with this is that it is hard to maintain, especially when the database changes or there are many foreign keys involved.
• restore a fresh copy of the db at the beginning of the test so you always have the same initial data. This is time consuming and the initial state of the database might change over time so you might have to manually maintain the “fresh” database.
• use the rollback mechanism of the database.

If we are using NUnit and SqlServer the third choice is an easy one both in implementation and maintenance. There is a mechanism provided by TeamAgile which lets you specify that a test should have the data rolled back when the test ends. The idea is simple. When the tests starts, it informs the database that all the operations in the current thread context will be executed in a transaction and at the end it will instruct the database to do a rollback. The maintenance is eased because the database you use can be a copy of the live database and this suffers no data changes from test to test.

Now we get to the hard part. NUnit test data rollback is solved but lately all big web application also use automatic tests for the interface. The tools vary: Selenium, QTP, WatiN (our choice) or others. Now for this tests data rollback cannot be used like in the case of NUnit because each request gets it’s own thread context and all the other methods have their problems as stated above. So we get to the same problem. How can we do data rollback in automated web tests?

The solution I chose is easy, but depends on the data access layer implementation. For example we have a single point where SqlCommand’s are created and that is good because we can use transactions. The idea is simple; any time a database call is made we check if we have a transaction started and if so then we will execute the call within the existing transaction. But this is implemented in the data layer and our tests are done on the interface layer and we have to somehow connect them.

Create a special page where you  have two buttons and a textbox. One button is for starting a web transaction and one for rollback -ing a transaction. When the start button is pushed we make a call to the data layer to create a web transaction. This looks in a dictionary and gets us an unique id (i.e. an int) which will identify our transaction and this id we will show in the textbox and our tests records it for later use. Then we do our tests in the web pages like usual. When we finished we go to the same page enter in the textbox the transaction id and instruct to rollback.

I will post later some code to this so stay tuned …

This entry was posted on Monday, January 5th, 2009 at 11:37 am and is filed under .NET. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.