Test-driven Development: Specification Documents and Unit Tests

In this article we’ll take you behind the scenes of the development of the new Risk Finder’s ‘risk inspections’. We’ll explain how we classify risks and how we maintain the quality and speed of the software.

The results of these ‘risk inspections’ are presented to the end user based on risk level and risk category, and with suggestions for improvement. Each risk is described thoroughly, and, where possible, also illustrated visually. In addition, the Risk Finder refers back to the location of the problem in the original Excel file with a link, so that the problem can be solved immediately.

Specification Documents

For every risk that the Risk Finder can find in theory, we’ll build a specification document. This is an Excel file (what else!) in which we include all possible forms of that specific problem. For each instance we determine whether it poses a direct risk, whether it concerns a weakness of the model or whether we only want to refer to it as an observation (with unknown impact).

Before we start programming, for each manifestation, we discuss whether an inspection should trigger or not and how to classify the risk. We do this as a team, based on the many real live examples and experiences we’ve gained over the years. By discussing all perspectives on a risk in detail, we rarely come to new insights later in the process and we avoid having to revise written code later on.

Test-driven Development

Once we have fully established the classification of the various manifestations of a specific risk, we develop unit tests. Unit tests are pieces of code that define what the outcome of a particular inspection should be. For example, if we have processed 23 examples of hard-coded numbers on a specification document, we will also develop 23 unit tests. This way we can validate on a case-by-case basis whether the code we write does as we intended.

A unit test checks one part (unit) of the program. Checking all parts separately, allows us to focus on specific functionalities during development and to know exactly what is broken if something goes wrong. Currently we have approximately 600 unit tests for all inspections that the Risk Eliminator and Risk Finder perform. In only one click we can check whether all inspections still give the desired results when we adjust code.

Unit Tests Make Programming Fun

When we start with the actual implementation (when we start teaching the program to detect the problem in Excel), all unit tests initially give wrong results. All check marks are red, because the code is not yet compliant; the problem is not yet recognized. And every time we program a step in the right direction, a number of check marks jump from red to green. As soon as everything is green, the code is ready for use; then the results are exactly as we determined them beforehand.

Advantages of Unit Tests

As mentioned, when we change something in the code, we will immediately see it when one of the check marks turns red again. We immediately know where the problem is and we can repair it quickly and efficiently. That is a big advantage of working with unit tests.

Unit tests also make it a lot easier to improve the speed of the software. We don’t want our customers to have to wait too long for an analysis, so we spend a lot of time on optimizing the performance. As we implement more inspections, more options for optimization arise. That is why we regularly reexamine pieces of code to see if there are possibilities for improvement. If this is the case, we rewrite that part in such a way that the result remains the same, but the calculation process becomes faster. Redefining a very complicated implementation takes a lot of brain power; it’s hard to predict whether it will theoretically give the same results. Thanks to the unit tests, we can validate the changes in no time; when all unit tests return a green check mark, the optimization is successful.

Limitations of Unit Tests

However test-driven development is now a fairly standard approach in software development, it does have its limitations. We mainly test the operation ‘under the hood’: the powerful spreadsheet analyses. But the so-called ‘front-end’ (the buttons, the colors, and pictures) is not included in the unit tests. Something that goes well ‘at the back’ must also give a logical and readable result ‘at the front’. However, that process is not as exact, as it involves front-end design. Before we release a new version, we always do a test sprint first; we spend two full weeks in which we fully focus on testing the front-end. In other words: does the tool really represent the problem, would I understand what is written here if I did not know the tool or if I were not familiar with this Excel model, can I click on a formula and will I be taken directly to Excel; those checks are all done manually.

See all blog articles