Entries from November 2007 ↓

I often get asked questions about how to test code that relies heavily on a database. People often assume that because an application relies on a database that the test must also rely on a database. Then they get snagged up in all the problems with testing against databases such as not messing up the data for other people and being able to setup the data so that the test can expect a certain result when the Company table is queried for companid 1357, or even which company should be queried for?

“I need a Company record that has more than 500 employees and is publicly traded to test this bit of logic I wrote. Which companyid should I use? Is the data going to change? Should I just create a new test company in the database? I hope nobody touches it.”

My short answer is: Don’t include the database when you’re testing your business logic (unless you are testing business logic that’s in the database, but that’s a whole seperate topic that won’t be covered here).

How do you do that?

1. Seperate the code that accesses the database from your business logic implementation.
2. Create a well-defined interface for that data access object. Like ICompanyDataAccess.
3. Test the business logic by plugging a Mock object in to replace the database implementation of the data access object.

For further reading, refer to this excellent blog post on mock testing with NMock:  http://msdn.microsoft.com/msdnmag/issues/04/10/NMock/

Comments, questions, or experiences relating to mock testing or seperating business logic from data access? Please comment below.

Okay, that was easy!

I have three separate Watir scripts written to open IE and:

1. Automatically login with a valid test username and password
2. Login with a valid username and invalid password
3. Login with a non-existent username

Manually each of these procedures take about 25 seconds. Running these using Watir from my ruby editor takes about 5 seconds. That’s 5 times faster!!!

If I estimate that I need to log into that app 100 times today to do my manual testing, I’ll be spending 8 minutes logging in rather than  42 minutes. I’m already going to save aproximately 2,000 seconds or 33 minutes of wasted time (it took less than 5 minutes to write the scripts). Multiply that by 10 developers and that’s a savings of over 5 hours per day! That could be another feature.

I’m changing some untested code today and I want to make sure I’m not breaking things as I go, but I don’t want to slow down my development because timelines are tight.

I’m going to use Watir and WatirRecorder (was WatirMaker) to help speed up my manual testing through the user interface. If that goes well I might add some asserts where it makes sense. If I have time I’ll check out WatiN as well.

I’ll write another post to let you know how it went.

I just read a great post that describes and compares the often confusing and scary landscape of patterns for achieving separation of concerns in applications requiring user interaction.

http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html

On Friday I held a class on test driven development for the group of developers that will be expected to start developing using TDD soon. For many it will be their first experience with TDD.

I demonstrated how to do TDD in a live coding session where I rapidly added features to a web service application by cycling through the red-green-refactor process several times.

I think the concepts and practices were well understood by everyone and I’m hopeful that we’ll be successful in migrating from a non test-driven culture to a test-driven culture.

The questions after the coding session were mostly focused on how to test the existing code; the code that has low cohesion and high coupling; the stuff that’s hard to test.

How to start testing large, untested applications

I suggest the following approach:

1. rank application features by total cost of ownership by looking at how much time and money is spent fixing defects and handling customer support issues
2. look at upcoming feature requests and consider where the system needs to be changed

Start by testing the areas that cost the most to support and the areas that need to be changed significantly or frequently.

Choose black box tests that cover the visible features rather than the implementation details behind those features.

Use tools like WATIR or WATIN to assist with manual testing by using them to execute test setup while still using manual verification.

There is no silver bullet. Untested codebases are expensive to test. In general I think the best you can do is to control costs, focus on tests with the highest potential ROI, and ensure that new features are tested.