Tag Archives: tdd

A unit test suite is a spiderweb

Leave a reply

A moment’s epiphany in a highly caffeinated brain; a metaphor:

a unit test suite is a spiderweb![1. When done well]

Why?

  • It’s lightweight
  • It’s sufficiently robust
  • It catches a casual bug passing by
  • It’s most useful if the maintainer reacts to a bug catch immediately
  • It needs occasional maintenance
  • It’s not watertight, but good enough
  • Some are beautifully designed, some look like a tight cloth, some are a mess
  • …insert your analogy…

There is an already established XP metaphor of a safety net for the people and the business, to which I fully subscribe. This “lightweight net” metaphor, I hope, adds another flavor to the test-suite-as-a-net analogies, especially, to lightweight unit test suites, by describing which qualities unit test suites can have.

We now know that small (biological) bugs and other small creatures can cause a lot of harm, just as tiny software bugs can and do. [1. As a corollary: one can catch larger things by being a large cat, and applying different powerful strategies, but that requires quite a muscle mass, and a good connection to the ground. P.S. no lightweight vs. non-lightweight preference comparison intended.]

The analogy might have been a cheap trick of my brain. Nonetheless, it is now externalized, and I can go to sleep.

Build Status

Presenting at TU-Munich: testing on c++ projects, Thursday, March 26, 2015 7:00 PM

Leave a reply

Expecting Thank you to all for a superb heated debate! next week

“no excuses for not testing on c++ projects”

Thursday, March 26, 2015
7:00 PM

details: http://www.meetup.com/MUCplusplus/events/220628575/

If only all test were comprehensible…

SCENARIO("acquiring wisdom") {

  GIVEN("an oracle") { 
    oracle gus;
    
    WHEN("I ask it to speak") {
      auto answer = gus.speak();

      THEN("wisdom is apparent") {
        CHECK( answer != "bla" );
      }
    }
  }
}
[1. Catch]

→ The code can be found @github, including the presentation slides.

Setting travis-ci with github for a c++ project for the first time

Leave a reply

Intro

Here, I’m trying to use travis-ci, c++, github, CATCH, premake together with my undoredo-cpp library to reduce entropy, try out continuous integration and behavior-style tests.

As a “one-man show” programmer at least at home, I’m trying to keep the discipline of writing tests first. “Growing Object-Oriented Software Guided by Tests” is perhaps a good, although a comparatively dry book for those who are not yet convinced. The blog post by Phil Nash about his latest version of the c++ single-header testing framework CATCH, moved me to finally get my hands on the free continuous integration service travis-ci, along with CATCH with a goal to rewrite the tests for my undo-redo c++ adventure in a more behavior-driven-style.

The undo-redo library is already there, and the tests as well – in gtest (see the master branch). I’d label them “explorative” at the moment since there are just too many assertions per test case, which means I’m repeating myself.

Starting continuous integration at travis-ci for c++

To start my CATCH-“BDD” exploration I’ve setup the branch first: https://github.com/d-led/undoredo-cpp/tree/catchmoci. At my landing page the project is switched on for catching the commit hooks:

travis_setup

The following configuration file .travis.yml is placed for travis-ci to know what to do with my non-conforming repo:

language: cpp

branches:
  only:
   - catchmoci

before_script: ls

script:
  - make -C Build

As in all TDD practice, the build fails due to the reason that the build doesn’t work yet at all. Adding a status image to my README shines:

failing

Fixing the build

The makefiles are created using premake4, which is a single-file makefile generator based on lua. Unfortunately, I couldn’t force the CI-virtual machine execute my binary premake4, so I had to add the generated makefiles. Now that the make process works, the tests still don’t compile:

failing

Fixing the tests

Once the bulk of the assertions have been rewritten for CATCH, the build still failed due to an ambiguity in serializing std::nullptr_t. Fortunately, Phil has thought of (or rather tested) that, and has a macro which can be defined for the build, fixing it: CATCH_CONFIG_CPP11_NULLPTR.

Voila, travis-ci vm is happy:

passing

Just checking locally if test reporting is fine by adding a spurious test temporarily:

justchecking

The test-rewrite has been successful and all pass, the badge is green and I can go to bed

passing2

But! It’s not the end of the story! BDD! Mock-objects!