Gherkin

BDD testing C++ Library

Why should a tester who focuses on use cases and requirements use highly specific and complex C++ language?

If the software architecture is already thinking in components and concerns, there will probably be a library that we can test.

So how can we use for example python for testing C++ libraries in an easy way?

Specification development – Treasure hunt

As an example for requirement writing, i’d like to create an Application that allows us to do some treasure hunting. Furthermore I’d like to use the Gherkin BDD pattern to write the requriements.

Let’s start with basics, an abstract description of the app as free text and scenarios.

Feature: Treasure Hunt
The player gets some hints or facts to a sight and then gets the task to guess and move to the sight. If the player arrives at his guess, the position can be submitted and is validated if the guess is correct.

Scenario: Asking for new sight
  Given I as a Player
  When Asking for a new sight to guess
  Then I'm offered some facts about the sight to guess

Scenario: Submitting guess
  Given I as a Player
  And I'm given hints for a sight
  And I'm close to the correct sight
  When I submit my position
  Then I'm notified, that it's correct

Cool, we have our first requriements and we also managed to just describe the behavior without digging into solutions like which button to press or how we get and display the facts or even how we get the position.

But what fun would it make if the player always would directly know where to go? We probably need some case, where the player submits some wrong position.

Feature: Treasure Hunt
The player gets some hints or facts to a sight and then gets the task to guess and move to the sight. If the player arrives at his guess, the position can be submitted and is validated if the guess is correct.

@basic
Scenario: Asking for new sight
  Given I as a Player
  When Asking for a new sight to guess
  Then I'm offered some facts about the sight to guess

@basic
Scenario: Submitting guess
  Given I as a Player
  And I'm given hints for a sight
  And I'm close to the correct sight
  When I submit my position
  Then I'm notified, that it's correct

@alternative
Scenario: Submitting wrong guess
  Given I as a Player
  And I'm given hints for a sight
  And I'm not close to the correct sight
  When I submit my position
  Then I'm notified, that it's incorrect

As you see, I already added tags “basic” and “alternative” to the scenarios. That way we can directly see if the scenario is in basic flow or handles some deviation.

This further detailing can be continued with scenarios for increasing player points, giving up and selecting a new sight or allowing only some amount of wrong guesses.

Also what about adding new sights and facts about them? As we probably don’t want to fiddle with the database directly, we probably need some administrator tool to add and modify.

Feature: Sight maintaining

@basic @admin
Scenario: Add Sights
  Given I as Administrator
  And admin tools
  When sight 'Garden' is not existent
  Then I can add new sight 'Garden'

@basic @admin
Scenario: Add Facts to Sights
  Given I as Administrator
  And admin tools
  And Sights are
    | Name |
    | Berlin Gate |
    | Church |
  When editing sight 'Garden'
  Then I can add new facts to 'Garden'

BDD Testing C++ Library with Python Behave

Let’s try to test a shared library (.dll or .so) with python.

You can clone the code from: https://gitlab.com/dominik.gausa/bdd-test-shared-library

C++ shared library

Our library under test exports some basic functions

// Lib/src/lib.h

LIBRARY_API void api_say_hello();
LIBRARY_API unsigned int api_call_count();
LIBRARY_API int api_sum(int a, int b);
LIBRARY_API float api_vector_size(struct vector_s* vect);

Specification by text

After having done a brainstorming on use cases and activities, it’s time to formulate these in textual form.

Shall, should, can

For requirement engineering often the pattern “if …, the … shall/should/can do …” is used.

If logged in, the user shall be able to interact with the software
If not logged in, the user shall be redirected to the login page
If user does not have an account, the user can create a new account

This already breaks down a otherwise big block of text into smaller patternized atomic actions and features. Further allowing grouping some of them and mapping them to components in following steps of design.

An alternative is to use Gherkin, which is a specific language for behavior driven design (BDD), designed by Cucumber.

In Gherkin single requirements are “Scenario’s” made of steps written in a specific form.

Given – What is the (static) precondition
When – Define a Trigger
Then – Observable resulting behavior

This pattern pretty much matches the brainstorming we started with.

The benefit, that let’s hearts of testers jump higher is, it’s an standardized format that already has multiple implementations for Testframeworks. So a tester can use the requirements directly as input for tests and can focus on implementing the necessary steps.

C# – Specflow
Python – Behave