First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

I've to admit it: I never wrote many tests for the code I wrote. Probably one of the reason is that the last time I wrote something from scratch, with enough time to convince the other members of the team to try a new approach, was before the TDD became known to the general audience. I only wrote some test for small part of the code, or to expose some bugs and later fix them.

But 2 months ago, I had to design from scratch a small web application: and again I didn't have the time to sit down, look around and try a TDD approach for it. So I ended up writing my Data Access Layer, my Business Layer and testing them trying them out with a console application that acted as a client for the DAL and the BL.

But while writing in my console application the code to call the DAL, I noticed that it was the same code that I would have written inside a unit test. The difference is that you cannot check automatically if the console application behave correctly, but you have to do it manually, stepping thorough the code and checking if the database is populated with the correct data. 

That was a small project so I went on with the console application approach, but I promised that my next project would have been developed using the TDD approach.

Two weeks ago I started a new project, and I decided to use this approach: I write my DAL and, instead of trying it with some code that will be thrown away, I test the functionalities inside a unit test. And it's even easier to work with because you can choose which test to run, you can have a coverage report on your library and, if the application is well designed, you can even test the UI or the Business Logic without hitting the database, using some mocking library.

So, if you want to find a practical reason to start writing unit tests think about this:

If you write any library (a DAL, some Business Logic, some general purpose utilities), you have to try it somehow. And to do it you have to write some code just for testing: so why don't you put the same code inside a unit testing project? With the same effort you will have "best-practice" testing procedure to improve a lot the quality of your code.

This was the motivation that worked for me. I hope it will convince also other people to write more tests for their code.

Technorati tags: ,

kick it on DotNetKicks.com

posted on Saturday, June 16, 2007 1:40 AM

Comments on this entry:

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by Simone Busoli at 6/16/2007 6:18 AM

Isn't a SubText team member supposed to do TDD? ;)

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by simone at 6/16/2007 10:48 AM

Not necessarily: SubText is not developed with a TDD. But in the last months we are trying to write more tests for our code.

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by Steve Harman at 6/16/2007 5:45 PM

For the record: the Code Coverage for the Subtext Trunk is now over 45% - which is a long way from where we started... 0%. :)

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by roberto at 6/18/2007 10:00 PM

Have you already written tests on inserting and retrieving data with database ?

I've never used TDD, I mean seriously.
I "played" with TDD sometimes in small projects, or very small areas of big projects, but working with databases always stopped me to implement TDD seriously.

All those insert and delete, don't match with a database life, and with test goal too.

I had some idea to solve this problem, but I need more time to test them.

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by simone at 6/18/2007 10:11 PM

Have you tried using mock objects?
I had time to experiment with them, and they are very useful when it comes to testing a layered application.
To test the Database I only make one test, a CRUD test:
I insert, get, update, get, delete, get.
This way the db is always in a known state.

# How to mock a NHibernate Repository

Left by CodeClimber at 6/18/2007 11:18 PM

How to mock a NHibernate Repository

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by Sérgio at 6/19/2007 4:10 AM

Check Ayende's site (http://www.ayende.com/) for a nice mocking framework to test your repositories.

# re: What convinced me to adopt a (kind of) Test Driven Design approach

Left by Simone at 6/19/2007 9:51 AM

Sergio is referring to Rhino Mocks, the same mocking library I was referring to:
I wrote an introduction to it:
How to mock a NHibernate Repository with Rhino Mocks

Comments have been closed on this topic.