5 - Intermission

Jun 14, 2021 tdd rust srl | Prev | Next

This post is part of the series Making a Roguelike - A test-driven approach.

Let’s take a breather and zoom out a bit to look at what happened so far:

Testing Strategy

So far, we have seen two types of tests: Feature tests and unit tests.

A feature test usually simulates the input and asserts against some expected output. It will instantiate everything that is needed in between. I call it a feature test because it verifies a user-facing behavior, aka a feature.

A unit test usually instantiates a single “unit”, in our case this will usually be a module or a struct.

More important than this distinction by shape, is the distinction by purpose.

A feature test is generative. It generates forward momentum in the project. It generates the design needed to make it pass. And I don’t mean that in any kind of automated sense. It generates thoughts like “How much design to I need to write the test?”. And after the test is written, the design can safely come to be.

A unit test is assertive. It is the workhorse for the underlying implementation. It is not overly concerned with design. It is used to fill out the leaf nodes of the design, if you will.

With this distinction, I use a slightly modified version of the usual Red-Green-Refactor loop:

So there is an outer loop and an inner loop:

Feature tests typically fail for a while. That’s OK. We use the inner loop to fill out the details, as it were.

So this is the strategy. There are glimpses of it in previous posts. Somewhat ironcically, unit tests were only used to implement test helpers so far. But this will change.

Let’s see how this works out! There will be many intricate details to negotiate, and trade offs will have to be made.

I have another tiny list that will complete what I would call “Version 0” of the game:

- [ ] Player collision with walls
- [ ] Player collision with enemies (no combat)
- [ ] Randomly generated walls

On to player collision then!