Difference among goals of DBC, AOP, TDD and Unit tests

Question

I've read about all those approaches: Design by Contract, Aspect Oriented Programming, Test Driven Development and Unit testing. In practice I've used only Unit tests and AOP (AspectJ). I know that that are the different things but seems I've got some delusions about their purposes.

Question\Request: Can you provide a brief survey for differences among purposes of DBC, AOP, TDD and Unit tests? Can you review my conclusions about it and point me where I'm wrong?

My conclusions:

1. DBC vs Unit tests: DBC describe a invariants contrains, whereas Unit tests enforce them. So you use Unit test to check if all works correct, and DBC to make your code more clear for customer. Am I right? If you have Unit tests for what you may want to use DBC? Just for readability?
2. DBC vs AOP: AOP can be used both for checking contracts and for another pusposes, such as logging and so on. I use AspectJ also for server-side validation. Than AOP is more wide concept which contains DBC too. Am I right?
3. What are the differences in TDD and DBC purposes, or TDD and AOP?

Answer 1

IMMO DBC, TDD and AOP are not directly comparable, are very different things with very different purposes, i try to explain what this techniques are in my personal view:

• DBC purpose its to define semantics (in the form of preconditions, postconditions and invariants) for ensuring the correctness of a piece of code. Depending on the implementation of DBC this contracts can be asserted in runtime or can be try to be enforced in compile time. Honestly i have to say that i never use and i never see a real system build with DBC, there isn't good tool support for DBC and there is very few practical advise in the use of DBC.

• TDD its about ensuring correctness through the use of examples (aka tests), also TDD its a design technique using the rapid feedback cycle red-green-refactor. Like DBC its a technique for build software with no defects, but with a really different approach. I use TDD in a lot of projects for more than six years (or a little more i don't remember) with good results, for me its now the "natural" way to develop software, off course this is a personal choice not a general recommendation, try by yourself.

• AOP its another very different things, its a way to deal with cross-cutting concerns, you can use this for verify the enforcements of contracts?, probably yes, but this its not more than one of the infinite uses of AOP. Only my opinion, i'm not a big fan of AOP, i have to maintain legacy codebases with a lot AOP stuff, and IMMO AOP its a very sophisticated way to hide important functionality of your system.

Answer 2

I'll take a stab at this ...

• DBC - This is an programming approach that is easier to understand when contrasted with defensive programming.

  • Design-by-contract is about fully specifying who (feature client or feature provider) is responsible for what (the contract). The feature provider promises: if you meet my preconditions (e.g that the input value is non-negative), then I guarantee my post-conditions (e.g. then I will return the square root of the value). An equally valid contract is: if you give me any number at all (no precondition), then I will do return -1 if it is negative, otherwise I will return the square root of the number.

  • With this approach, the feature client is clearly responsible for checking the preconditions are met before calling the feature. The feature provider is free to assume the preconditions are met but it must ensure it meets its postcondition.

  • Contrast this with defensive programming where both the feature client and the feature provider will be validating data just in case the other one won't be.

  • DBC attempts to help devs create correct code by reducing its complexity (stronger specs and less duplicate code).

  • How DBC is implemented is an implementation detail of sorts. You can do DBC without any tool support just by full defining the API on paper and then implementing it so that clients are checking the (specified) preconditions and providers are meeting their postconditions (for all valid preconditions). Of course, tool support helps ....

• Units tests are simply a way to ensure your code behaves as you intended (one of several). You can use unit tests on DBC code or non-DBC code. Unit tests and DBC are complementary in a way because its easy to write a unit test for a well-defined API spec; on the other hand, they can be even seen duplicative if you are using a tool to support DBC because the contract may end up being described/verified in both the unit tests and the DBC tool.

• TDD is another approach to reduce complexity in developing code from a different point of view. Start with a spec for a feature, write the test for it (it should fail), write the production code that to make the test pass (and no more). TDD code could still use DBC (or not).

• AOP is more like a technology - its an alternative way to get bits of code to run where you want it to. It can be used to support a lot of things, but I wouldn't say "AOP is more wide concept which contains DBC" any more than I would say that a pen is a wider concept than a short story.