I've been meaning to blog about this article, to recommend it to everyone starting out with TDD (but since you get a lot more traffic than I do, why not write it here will people will actually see it?).
You really did a fine job of capturing the common gotchas, and giving good guidance for how to approach writing your tests. A lot of other sources tell you "what" and "why", but its tough to find a good source on "how". This is it. Thanks a lot!
I was expecting something more than a test for a sum, there are many people that talk about TDD, but very few show actual code for more complicated scenarios, specially when using data (databases, xml, whatever files, etc), or how you separate the test code from the production code, etc
congratulations Roy! It's definitely on my reading list in the near coming days..
Roy you mention in your article that you should "Avoid Dependencies Between Tests". I sometimes call one test from another to ensure that data/state is setup for this test to run. It does require that the other test is run before hand, but I guess it does create a dependency between the two.
What do you think is a better alternative to this? Like a database setup and tear down scripts for the test suite? Or to use the setup teardown sections of the test to seutp this data?
Great thanks for the tips Roy
Great article Roy (as usual) :)
One thing I was thinking about, on multiple asserts. I mostly agree with the single assert per test, but sometimes I feel that we're just not using multiple asserts because the framework simply doesn't support that, and no other "best practice" reason.
Why not supporting code like:
AssertGroup agroup= new AssertGroup();
agroup.add(new AssertEqual(...));
agroup.add(new AssertNotNull(...));
....
agroup.AssertAll()
Could this reduce some test code? Probably. Is it a good ideia? Don't know yet.
Another possible conclusion is that, currently, the feedback we get from tests is very limited (to a failed single assert).