Search code examples
unit-testingarchitecturetddaopdesign-by-contract

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

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?
Solution

  • 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.