Tag Archives: programming

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


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:


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

language: cpp

   - catchmoci

before_script: ls

  - 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:


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:


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:


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


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


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

Self-destructing objects

One day, recalling the programmed cell death I decided to create class that would self-destruct on a certain amount of copying.

Today’s little research resulted in the following project: https://github.com/d-led/selfdestructing

The question arises, what exactly copying stands for. I could think of four policies. The implementation of those policies is configurable and extensible. Right now there is no explicitly thread-safe policy implemented, but those would not be very complicated, if the purpose is debugging solely.


#include "crash_on_copy.hpp"
struct TestNumberCrash : public crashes::on<3>::copies {};

on_copiesCrashes on 3 total copies of the originally created object, but doesn’t crash on 3 total instances of the class

struct TestCopyNrCrash : public crashes::after<3>::copies {};

after_copiesCrashes on any third copy of the original object, but doesn’t crash on 3 total instances of the class

struct TestTotalNrCrash : public crashes::on_total<3,TestTotalNrCrash>::instances {};

on_total_instancesCrashes on instantiation of an object if 2 objects are alive, but doesn’t crash on any creation if the total amount of instances is below 2

struct TestAfterTotalNrCrash : public crashes::after_total<3,TestAfterTotalNrCrash>::instances {};

after_total_instancesCrashes after a third object instantiation of the class

Singular form aliases are also available, i.e. crashes::on<1>::copy.

The project at github contains the test showing the crashing pattern.