Welcome back to the new issue of “Build Your Own Testing Framework” series! Did you notice, that out testing framework quits on the first failure? It probably should run all tests, collect all failures and present them nicely. This is what we are going to accomplish today:

• Make sure all tests run even when there is a failure.
• Make sure exit code is correct.

Hello everyone! I’m usually advocating for the Baby-Steps Test-Driven Development with Triangulation. On the first encounter, this technique seems very verbose and everybody wonders how can it possibly work and why I am very productive with it. Let me tell you about that. First, let’s quickly recap both techniques:

Hello, everyone. Today we will take a look into a little problem involving high scores in some sort of game. The game has only one high score and when current game’s score exceeds that number, it gets updated. Example acceptance test would read like this:

Given high score is 174
When player scores 191
Then high score is 191

Duck type

Duck type is the concept in the domain of the type safety that represents objects, that pass a so-called “Duck Test”:

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

In terms of programming language, it might look like this:

1
2
3
4
5
6
7
8
9
10
11

function Duck() {
    this.swim = function (coordinates) { ... };
    this.quack = function (sentence) { ... };
}

function RoboDuck() {
    this.swim = function (coordinates) { ... };
    this.quack = function (sentence) { ... };
}

// .. and so on ..

A test double is a test object or a test function, that looks and behaves like its production counterpart, but is actually a simplified version that reduces the complexity and enables simpler testing. One can represent all types of test double as an inheritance tree like this:

Where Double is an abstract test double, which has no functionality - it is a general concept to talk about test doubles.

Welcome back to the new issue of “Build Your Own Testing Framework” series! As you might have noticed, currently, our testing framework only outputs failures and nothing else. It is impossible to know if it actually runs any tests when they all pass because there is no output. Today we will implement a simple reporter for our testing framework. It will report the name of the test suite and names of the tests that are being executed, for example:

1
2
3
4
5

SpyTest
    testIsNotCalledInitially
    testAssertNotCalledFailsWhenWasCalled
    testIsCalledAfterBeingCalled
    testAssertCalledFailsWhenWasNotCalled

This article is the fourth one of the series “Build Your Own Testing Framework”, so make sure to stick around for next parts! All articles of these series can be found here.

Shall we get started?

Welcome back to the “Getting Stuck While Doing TDD” series. Today we are going to learn the Golden Rule of TDD and how to not get stuck while doing TDD.

TL;DR

• “As tests get more specific, production code gets more generic”.
• RED is as important as other in Red-Green-Refactor cycle. If next test does not fail, it is either: already implemented, or has to wait until a later time (until it will fail).

• At its core the Triangulation Technique has the following idea:

  After implementing one business rule (with Red-Green-Refactor) make sure to find all “weirdnesses” or non-generalities in the production code and one-by-one eliminate them by writing a test, that proves such non-generality, and then making it pass while removing non-generality. This is the third cycle of TDD - Mini Cycle.

Welcome back to the “Getting Stuck While Doing TDD” series. Today we are going to see the results of getting stuck while doing TDD and scratch the surface of how to avoid this outcome.

Code examples today will be in Ruby programming language. The technique itself is, of course, language-agnostic.

TL;DR

• It is painful and difficult to force your way through when getting stuck in TDD.
• It results in degraded guarantees from TDD (such as test coverage, semantical stability, and confidence).

Ways to avoid this outcome:

• do not write tests that will not fail with the current production code
• choose next test to write that will address particular detail about production code that is wrong or not general enough (Triangulation)

Finally, do not forget to remove redundant tests if any.

Following 3 rules of TDD sounds really simple at first. In practice, there is a moment when one has to implement the whole algorithm at once to make currently failing test pass. This is called “getting stuck” in TDD. In this article, we will explore how exactly this happens and how to prevent that.

Code examples today will be in Ruby programming language. The technique itself is, of course, language-agnostic.

TL;DR

“Getting stuck” happens for a couple of reasons:

• wrong order of tests
• production code is not getting more general with each test

if statements tend to duplicate throughout the code base. This may lead to subtle mistakes and bugs. One way to avoid that problem is to eliminate if statement completely. Today we are going to take a look at one example of such elimination. Code examples today will be in Kotlin.