Software development: Test-driven development based on the St. Pauli School

Test Driven Development (TDD) is a popular and useful methodology. When used correctly, TDD significantly reduces the defect density without having to accept any loss of productivity. Above all, TDD helps to improve software design.

The article about the Munich school heise developer has shown the different styles or schools for test-driven development. Six representatives in particular stand out because they are well known and their concepts are well documented:

The St. Pauli school is related to the Munich school. It was initially only intended as a joking response to this, but has since evolved into a useful style of TDD in its own right. The St. Pauli school is characterized by six rules:

• Start at the API level,
• grow slowly and steadily,
• delegate sub-problems to stubs,
• replace stubs recursively,
• check the generality of the solution through a validation test and
• treat the test suite as “append-only” (no subsequent changes are allowed).

One of the main differences to the Munich school is the first test case. The Munich school uses a complex initial test that covers most of the requirements from the problem statement. St. Pauli, on the other hand, like London or Chicago, would like to start with the simplest possible test case.

The St. Pauli school in action – a practical example

In order to clarify the approach of the St. Pauli School, the well-known programming exercise Diamond-Kata, which the founder of the St. Pauli School Steven Collins also uses as an example, can be used, as in the article on the Munich School. The identical problem helps to better recognize the differences to the Munich school. The exercise has the following task:

Aim: For a given letter, a rhombus is output that begins with “A” and has the specified letter at its widest point.

diamond("B") generated

.A.
B.B
.A.

diamond("C") outputs the following:

..A..
.B.B.
C...C
.B.B.
..A..

Note: For readability, the sample code uses periods (.) instead of spaces.

The first rule says: “Start at the API level”. This does not mean an API in the sense of REST or a special interface. Instead, the API depends on the respective SUT (subject under test). It may be a service, a component, or a set of functionality, among other things. The level of abstraction varies from case to case.

While the Munich school starts with a more complex case like the diamond to “C”, St. Pauli starts with the simple “A” diamond:

describe("diamond", () => {
  it("should return the A-Diamond ", () => {
    expect(diamond("A")).toEqual("A");
  });
});

The next step is similar to Munich: Instead of a real implementation, a fake or stub ensures that the code passes the test. The term stub is different from the mock-like test stub from the test double category. A fake or stub is a piece of production code that pretends to be the right solution for the specific test case:

const diamond = (letter) => "A";

Here is the next test case at API level:

it("should return the B-Diamond ", () => {
  expect(diamond("B")).toEqual(".A.\nB.B\n.A.");
});

For this case it is necessary to extend the code:

const diamond = (letter) => {
  switch (letter) {
    case "A":
      return "A";
    case "B":
      return ".A.\nB.B\n.A.";
  }
};

Once a pattern is discernible between the cases, it can be extracted by refactoring. Since this is not yet the case, a third test follows with the associated fake for the “C” case.

it("should return the C-Diamond ", () => {
  expect(diamond("C")).
    toEqual("..A..\n.B.B.\nC...C\n.B.B.\n..A..");
});

const diamond = (letter) => {
  switch (letter) {
    case "A":
      return "A";
    case "B":
      return ".A.\nB.B\n.A.";
    case "C":
      return 
        "..A..\n.B.B.\nC...C\n.B.B.\n..A..";
  }
};

Different patterns can be recognized in the code, which a refactoring can extract. Kent Beck calls the principle, in which one first “fakes” several cases via branching and then extracts similarities, triangulation (1). It is the driving force behind the St. Pauli school.