First draft of C++ library contract_light published

 Uncategorized  Comments Off on First draft of C++ library contract_light published
Oct 212014

I am happy to announce that I published a C++ library that offers a lightweight version of a Design by Contract functionality. You can find it under

Here is a simple example for the beginning. More to come later

class Rect 
  // Use this define if an invariant is defined. If no invariant is defined
  // no need to do it
  int w_;
  int h_;
  Rect() : w_(0), h_(0) {}
  ~Rect() {
    // checking that the invariants are fulfilled, even before destruction
  void setWidth(int newW) {
    // setting the pre condition of this method; the invariant is checked 
    // once at the end of the scope
    PRECONDITION [&] { return newW >= 0; };
    // setting the post condition; the invariant is checked only once after 
    // leaving the scope, regardless of the number of pre- and/or post-conditions
    POSTCONDITION [&, this] { return newW == w_; };
    w_ = newW;
    // There is no need to define here INVARIANT here. This is done automatically
    // whenever there is a bool invariant() const method is defined
  int size() const {
    int result;
    POSTCONDITION [&] { return result == w_ * h_; }
    result = w_ * h_;
    return result;
  bool invariant() const {
    return w_ >= 0 && h_ >= 0;


Oct 032014

James O. Coplien started a discussion in May 2014 about the value of UnitTests and why most of them are waste. In August he added the 2nd installment.

In this context I hear often the argument that the majority of tests should be UnitTests over all others. Mike Cohn suggests this as well with the layout of his Testing Pyramid, because UnitTests can be executed faster. Robert C. Martin (Uncle Bob) is a strong advocate of this too – see one of his recent blog entries. Later on I will come back to his blog post and his statement that a UnitTest framework must not slow down the developers’ pace. But first to the “argument” that UnitTests can be executed faster than the others:

When I talk in the following text only about End-To-End (E2E) tests, then as a pars pro toto for all kind of tests that check not just a single unit, but complex business logic or complete features.

So shall we write UnitTests “only” because they are executed faster than E2E tests? This sounds to me like some kind of a workaround. Because we cannot get easily execute broader applied tests fast, we test something that we can test faster? Exaggeratory, isn’t it somehow similar to the old joke below?


Continue reading »