Develop products faster with Behavior Driven Development (BDD)

Behavior Driven Development, or BDD for short, is a software development approach that I have practiced myself. In my experience, BDD requires a little more resources initially, but in the long term it ensures significantly higher quality and simplifies the handling of changes. The highlight of BDD is that goals, requirements and results are recorded in such a way that they can later be executed as automated tests.

The following is a brief introduction to BDD and approaches to incorporating mechanics and electronics in addition to software.

BDD in software development

Let's take a trivial example, checking whether a chosen password fulfills all security criteria. (No discussion now, please, what a good password is) Traditionally, we would create the requirements, so:

• The function is intended to check whether a given password fulfills certain security criteria.
• The password must be at least 8 characters long.
• It must contain at least one capital letter.

We could then also create tests via traceability. We could even automate the tests via unit tests. If we do that, then we are almost at BDD.

With BDD, we drastically increase the coupling between requirements, tests and code. Using Typescript and the Jest test framework, we could create the following machine-readable specification:

describe('The password validation function', () => {
  it('checks whether a given password fulfills all security criteria', () => {
    expect(validatePassword('Abcdef1!')).toBe(true);
  });
  it('must be at least 8 characters long', () => {
    expect(() => validatePassword('Ab1!')).toThrow('Password must be at least 8 characters long');
  });
  it('must contain at least one capital letter', () => {
    expect(() => validatePassword('abcdef1!')).toThrow('Password must contain at least one capital letter');
  });
});

We can see here that specification and test are extremely closely linked. For this reason, it is now even common practice not to store the test files with the extension .test.ts, but to designate them as .spec.ts, i.e. as a specification. The test parts of the describe...it components form complete sets that represent the requirements. For example, the output on the console looks like this:

 PASS ./passwordValidator.spec.ts
  The password validation function
    ✓ checks whether a given password fulfills all security criteria. (5 ms)
    ✓ must be at least 8 characters long (14 ms)
    ✓ must contain at least one capital letter (3 ms)
Test suites: 1 passed, 1 total
Tests: 3 passed, 3 total
Snapshots:   0 total
Time: 2.761 s, estimated 3 s
Ran all test suites.

Depending on how the development environment is configured, it can execute the relevant tests (and only these!) each time it is saved and indicate problems by means of syntax error markers.

BDD in Systems Engineering

BDD works excellently in software development: on the one hand, we now have excellent tools there. But more importantly, the process of "building the product" is virtually free! If we develop a rocket engine, for example, we can't just build it to check that the minimum thrust is generated and that the thing doesn't blow up in our face.

Building software is virtually free. However, we cannot "just" build the hardware product (or even just one component) in order to test it.

But a lot has changed here in the meantime. Specifically, we can build elements "quickly": 3D printing is already being used today for prototypes (mechanics). For electronics, too, there are now various solutions for producing components in days or minutes. For example, some electronics can be emulated.

Simulate instead of build

But the most important way to automate hardware and electronics testing is simulation. Matlab Simulink has been around since the 1980s and has been used for this purpose for almost as long. However, what is often missing is the strong link to the requirements that BDD actually demands. In this area Valispace and Flow Engineering pioneering work.

BDD and MBSE

Also MBSE enables BDD in product development. Finally, MBSE enables the integration of mechanics, electronics and software in a common model. By modeling system behaviour, requirements can be recorded as behavioral descriptions in a similar way to BDD. The tools also support simulation and static validation.

However, I see two problems with MBSE: Firstly, the usability is lousy (to put it mildly): The popular tools are all from the 1990s, and you can tell. The tight coupling that I described above does not manifest itself here.

In addition, MBSE too often develops into a silo that is not well integrated with the rest of development. In particular, there is no connection to design (including CAD) or electronics development. Even worse, good integration with test systems is often lacking in practice. The potential of BDD has to be laboriously tapped, if anyone makes the effort at all.

Conclusion

BDD has great potential in systems engineering. By closely linking requirements, specifications and tests, development processes can be made more efficient and product quality can be significantly increased. However, there is still a lot to be done, particularly in terms of the user-friendliness of the tools and the seamless integration of BDD into development processes.

It remains exciting to see whether and how BDD will establish itself in product development and which innovative solutions will emerge to close the gap between requirements and implementation even better.

Image source: Wikimedia