executable specifications for c++

import store;

import kaffeeklatsch;
using namespace kaffeeklatsch;

kaffeeklatsch_spec([] {
    describe("a shopping cart", []{
        it("can be filled with articles", []{
            auto cart = make_shared<Cart>();
            auto article make_shared<Article>("Ketchup", 3.99EUR);
            cart.add(article);
            expect(cart).to.have.sizeOf(1);
            expect(cart.total()).to.equal(3.99EUR);
        });
    });
});

int main(int argc, char *argv[]) { 
    return kaffeeklatsch::run(argc, argv);
}

this unit test library is a c++ variant of mocha/chai, which is a variant of rspec.

the mindset behind it is to regard tests not just as mere tests, but foremost as executable specification and documentation.

• tests can capture the most expensive part of software development: figuring out what it is that needs to be build.

• the test's names serve as documentation to the user of the unit under test.

• the test's body is an example to the user on how to use the code being tested.

  one can duplicate such tests to learn how to use the unit by using it or to create regression tests with something does not work as expected.

• the test's body serves as executable specification which can be automatically validated. whenever the specification diverts from the implementation, the computer will tell you.

• tests, when done right, allow to refactor the whole implementation to keep it readable and extenable for future requirements.

• ...that unit tests are the least effective way of testing.

• ...that there two kinds of unit tests:

  • a social unit test sends and gets data to to and from the unit via it's api. but the test does not care what other objects the unit may use under the hood. only slow external services might be mocked using validated fakes.

  • a solitary unit test sends data to the unit's api and validates what data it is sending to other units. those other units are mocked. furthermore, if the mock returns data, the exact value should be of no relevance to the test, otherwise the test implementation will depend on the unit being mocked.

    this approach can be used in object oriented code, which, due to the information hiding principle, has no getters, and instead of asking a unit for a value, one tell's a unit to do something. (tell, don't ask rule).

• ...of context driven testing

• ...of shift-left testing

• ...of growing object-oriented software driven by tests

• steven r. baker's history of rspec
• rspec style guide
• rspec (ruby)
• mocha test framework (javascript/typescript)
• chai assertion library (javascript/typescript)
• bandit (c++)

"kaffeeklatsch" is an informal social gathering for coffee and conversation. the reason to choose this name was

• kaffee/coffee: to honour the mocha/chai javascript test tools i've working with for several years. and only while working on this library i learned that they were inspired by rspec.
• klatsch/gossip: i'm an advocate of xp, double-loop-tdd and 3c and hence to start by pairing with the user and writing down the names of acceptance tests.

thank you for your interest. i've tried to do this software in modern c++ but there is still so much for me to learn.

if you'd like to contribute, please fork on github and send merge requests.

keep hacking,

mark