Test Driven Development and Design By Contract – friend or foe?

in this post i’ll try to answer a legitimate question, relating to a comment due to my last statement that interfaces are poor contracts: why do we need contracts (in the sense of invariants, pre- and postconditions) when we’ve got unit tests right at hand, that could also test the stated conditions?

in fact, it’s very tempting to see unit tests as an all-embracing instrument to check and show that a class will behave correctly, making contracts kind of unnecessary.
i’ll try to show you that unit tests (as an instrument for test driven development) and contracts (as an instrument for Design By Contract) indeed share the same goals but aren’t competing techniques, rather than methods that could complement each other.

jFIT – a little brother for FIT

it’s common sense to test a single class inside of a unit test. you mostly hear about ‘class under test’ when talking about what to test and how to organize a unit test. have you ever wondered then why it’s called ‘unit’ test and not ‘class’ test? being pragmatic (well, of course we all are pragmatic and agile these days, aren’t we?), why not having a more coarse-grained unit than a class under test?

for example, you may have asked yourself more than one time, why not use JUnit for integration tests as well. having used FIT (Framework for Integrated Tests) as a very productive tool for such tests in the past, i wished to have a similar little brother for direct use within JUnit (let’s say for developer integration tests).
Especially when it comes to a wide range of combinations of input or setup data for the unit under test, an equivalent of FIT’s ColumFixture would be of great value.