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
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:
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 http://www.mockobjects.com/book/ which introduces mocks using the paradigm of interaction testing.
Posta un commento