5. Context, System Under Test & Suites

As mentioned earlier, Cgreen promotes the behaviour driven style of test driving code. The thinking behind BDD is that we don’t really want to test anything, if we just could specify the behaviour of our code and ensure that it actually behaves this way we would be fine.

This might seem like an age old dream, but when you think about it, there is actually very little difference in the mechanics from vanillla TDD. First we write how we want it, then implement it. But the small change in wording, from `test´ to `behaviour´, from `test that´ to `ensure that´, makes a huge difference in thinking, and also very often in quality of the resulting code.

5.1. The SUT - System Under Test

Since BDD talks about behaviour, there has to be something that we can talk about as having that wanted behaviour. This is usually called the SUT, the System Under Test. The "system" might be whatever we are testing, such as a C module ("MUT"), class ("CUT"), object ("OUT"), function ("FUT") or method ("MUT"). We will stick with SUT in this document. To use Cgreen in BDD-ish mode you must define a name for it.

#include <cgreen/cgreen.h>
Describe(SUT);

Cgreen supports C++ and there you naturally have the objects and also the Class Under Test. But in plain C you will have to think about what is actually the "class" under test. E.g. in sort_test.c you might see

#include <cgreen/cgreen.h>
Describe(Sorter);

Ensure(Sorter, can_sort_an_empty_list) {
  assert_that(sorter(NULL), is_null);
}

In this example you can clearly see what difference the BDD-ish style makes when it comes to naming. Convention, and natural language, dictates that typical names for what TDD would call tests, now starts with 'can' or 'finds' or other verbs, which makes the specification so much easier to read.

Yes, I wrote 'specification'. Because that is how BDD views what TDD basically calls a test suite. The suite specifies the behaviour of a `class´. (That’s why some BDD frameworks draw on 'spec', like RSpec.)

5.2. Contexts and Before and After

The complete specification of the behaviour of a SUT might become long and require various forms of setup. When using TDD style you would probably break this up into multiple suites having their own setup() and teardown().

With BDD-ish style we could consider a suite as a behaviour specification for our SUT 'in a particular context'. E.g.

#include <cgreen/cgreen.h>

Describe(shopping_basket_for_returning_customer);

Customer *customer;

BeforeEach(shopping_basket_for_returning_customer){
  customer = create_test_customer();
  login(customer);
}

AfterEach(shopping_basket_for_returning_customer) {
  logout(customer);
  destroy_customer(customer);
}

Ensure(shopping_basket_for_returning_customer, allows_use_of_discounts) {
  ...
}

The 'context' would then be shopping_basket_for_returning_customer, with the SUT being the shopping basket 'class'.

So 'context', 'system under test' and 'suite' are mostly interchangable concepts in Cgreen lingo. It’s a named group of 'tests' that share the same BeforeEach and AfterEach and lives in the same source file.