Saturday, September 15, 2012
From time to time I encounter a problem that seems pretty straight-forward to implement without TDD, but very cumbersome to do with TDD. Most of these cases have something in common: they describe interactions between the tested component and external parties. These external parties can be either the user, external system, or any kind of communication protocol. Here’s the simplest example I could think of: This is a simple console application that asks the user for his name, and then greets him with “Hello, “, followed by his name. Writing this application takes exactly 3...
Monday, March 28, 2011
According to good TDD practices a test should describe (and eventually test) a behavior and not the implementation. Because of that, one thing that is tricky to do in TDD is to write tests for a multi-threaded component.
One can argue that multi-threading is a non-functional requirement, and therefore shouldn’t be covered by behavior tests, but only by load-tests. I don’t subscribe to this approach for few reasons:
As I’ll show below, it is possible to describe a multi-threaded problem as a functional requirement.
Load tests are non-deterministic
Load tests usually take long to run, and therefore aren’t being run very...