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

Build Your Own Testing Framework. Part 3

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! Today we are going to unit-test runTestSuite function of our testing framework. Currently, only its happy path is implicitly tested via every test of the system. Additionally, this function’s unhappy paths are, in fact, untestable at the moment.

This article is the third 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?

TDD #6: Continuous Integration Training

continuous-integration, kata, screencast, tdd, tdd-screencasts, test-driven-development

Test-Driven Development Screencast #6: Continuous Integration Training

(Recommended to watch full-screen and HD: 720p or more)

List of all TDD Screencasts can be found here.

Summary

Today we are going to discuss Continuous Integration, what it is and what it isn’t. We will define best Check-Out/Check-In cycle. We will explore ways to train our Continuous Integration skills. And we will do some live coding on Kata with special restriction, that allows one to train such skills. Then we will draw a bottom line.

Thanks for watching! If you liked it, please share this article on social networks and follow me on twitter: @waterlink000.

If you have any questions or feedback for me, don’t hesitate to reach me out on Twitter: @waterlink000.