Build Your Own Testing Framework. Part 5

build-your-own-testing-framework, javascript, tdd, test-driven-development, testing, xunit

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.

HighScore Kata

clean-architecture, clean-code, javascript, kata, testing

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

Meet Duck Type

duck-typing, javascript, testing

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 ..

Introducing Test Doubles

javascript, test-doubles, testing

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.

Build Your Own Testing Framework. Part 4

build-your-own-testing-framework, duck-typing, javascript, tdd, test-doubles, test-driven-development, testing, xunit

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?

Getting Stuck While Doing TDD. Part 3: Triangulation to the Rescue!

getting-stuck-while-doing-tdd, problem-solving, ruby, tdd, test-driven-development, triangulation

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.

Getting Stuck While Doing TDD. Part 2: Buggy Code and Forcing Our Way Through

getting-stuck-while-doing-tdd, problem-solving, ruby, tdd, test-driven-development, triangulation

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.

Getting Stuck While Doing TDD. Part 1: Example

getting-stuck-while-doing-tdd, problem-solving, ruby, tdd, test-driven-development, triangulation

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