venerdì 3 ottobre 2008

Test Driven Development/1 [ENG]

TDD (Test Driven Development) became very popular recently thanks to Kent Beck and his eXtreme Programming books where it was first presented (as far as I know).
In an article about the subject (pertaining to smalltalk, but general enough to be adapted to many other languages) he describes his testing pattern.
There's a lot to say on testing, many frameworks and tools for different languages, many philosophical arguments and abstract concepts.
Here I only want to testify that, well, it worked for me: I find that it made developing and debugging a bit easier.
The strong points of TDD are:
  • you get to think about the structure and interface of your classes earlier
  • you develop faster because you have a tool that make you see your code in action earlier
  • you find bug earlier
So how do I do that? (NOTE: these are my personal preferences, your mileage may vary).
First I write the test. I had to force myself to do that, in the beginning, but then it came naturally. Since my IDE is Eclipse and it starts to complain as soon as you save a class with missing dependencies I then write the stub methods for the class I want to test just so the project compiles.
I then write tests for boundaries (null parameters, empty lists, maximum allowed size of containers) and for normal situations (your average data set), and then for exception handling. I write one or more tests for the same method with different data set. I prefer text files, constants or SQL scripts to initialize the database rather than using mock objects.
Then I run the tests. I expect every one of them to fail, of course.
After that I get to work on every method of the class under test, and every time I run the tests again until every one passes.
I will try and add some practical example in the next posts about this subject.

1 commento:

smartrics ha detto...

in relation to using mock objects vs. real containers, I think it's a good approach for boundary classes or wrappers around external interfaces. For business logic classes my take is that mock objects are after all more productive. Have a look at which introduces mocks using the paradigm of interaction testing.