Post cover

Triangulation in Test-Driven Development

Test-driven development (aka TDD) consists of 3 phases: the red, the green, and the refactor.

The transition from green to refactor phase involves the generalization of the code under test. Especially if you've been using the faking technique in the green phase.

The idea of triangulation is to use 2 assertions to drive a safer creation of the generic code.

Let's see in more detail how triangulation works.

Note: if you're not familiar with test-driven development, I recommend checking TDD in JavaScript video guide before continuing with the article.

1. Example: develop a sum calculator

A good way to understand the benefits of the triangulation technique is to follow an example.

Let's say that you'd like to create a simple function: calculate the sum of 2 numbers. And let's imagine that you're unsure whether the addition operator is the right way to implement the sum.

Step 1: red

When doing TDD, I always start with the simplest test possible. In this case, I'm going to import the sum function and check that it returns undefined.

First, you need to write the unit test of the sum function:

javascript
import { sum } from './sum'
describe('sum()', () => {
it('should execute', () => {
expect(sum()).toBeUndefined()
})
})

Of course, the test throws an error because the module sum.js doesn't exist.

FAIL sum.spec.js
● Test suite failed to run
Cannot find module './sum' from 'sum.test.js'

Step 2: green

Let's then create the sum.js module exporting a simple function with an empty body:

javascript
export function sum() {}

The unit test passes and I'm successfully in the green phase.

PASS sum.spec.js
sum()
✓ should execute (1 ms)

Step 3: red

Now let's continue with the proper addition testing. Let's update the unit test to verify whether the function returns correctly the sum of 2 numbers: 1 and 2.

javascript
import { sum } from './sum'
describe('sum()', () => {
it('should calculate sum', () => {
expect(sum(1, 2)).toBe(3)
})
})

Running the updated test triggers an assertion error because currently the sum() implementation does nothing.

FAIL sum.spec.js
sum()
✕ should calculate sum (3 ms)
● sum() › should calculate sum
expect(received).toBe(expected) // Object.is equality
Expected: 3
Received: undefined
3 | describe('sum()', () => {
4 | it('should calculate sum', () => {
> 5 | expect(sum(1, 2)).toBe(3)
| ^
6 | })
7 | })
8 |

Step 4: green

Because the green phase has to be passed as soon as possible (with any programming sins you can imagine), let's use a fake implementation and simply return 3.

javascript
export function sum() {
return 3
}

Now the fake function passes the unit test.

PASS sum.spec.js
sum()
✓ should calculate sum (2 ms)

Step 5: red

In the previous 4 steps, I followed the standard TDD. Nothing fancy.

Now starts the interesting part.

Instead of going to the refactor phase to write the sum implementation, and because I'm unsure that 1 assertion is enough to test my future generic code, let's get back to the red phase and write another assertion:

javascript
import { sum } from './sum'
describe('sum()', () => {
it('should calculate sum', () => {
expect(sum(1, 2)).toBe(3)
expect(sum(3, 4)).toBe(7)
})
})

This is the triangulation technique in practice: you use 2 assertions to drive the generalization of the code.

Running the test fails because of the second assertion.

FAIL sum.spec.js
sum()
✕ should calculate sum (4 ms)
● sum() › should calculate sum
expect(received).toBe(expected) // Object.is equality
Expected: 7
Received: 3
4 | it('should calculate sum', () => {
5 | expect(sum(1, 2)).toBe(3)
> 6 | expect(sum(3, 4)).toBe(7)
| ^
7 | })
8 | })
9 |

Step 6: green

Having the 2 assertions that check the future code, let's write the proper implementation of the sum:

javascript
export function sum(n1, n2) {
return n1 + n2
}

The unit test successfully passes. The addition code has been generated from the 2 assertions and now I have more confidence in the correctness of my generic solution.

PASS sum.spec.js
sum()
✓ should calculate sum (2 ms)

Step 7: refactor

Now the generic code is created and the assertions prove it working. You can remove one of the assertions:

javascript
import { sum } from './sum'
describe('sum()', () => {
it('should calculate sum', () => {
expect(sum(1, 2)).toBe(3)
})
})

Of course, running the unit test still passes.

PASS sum.spec.js
sum()
✓ should calculate sum (2 ms)

2. Triangulation

Having seen the triangulation in practice, let's formulate a simple definition of it.

Triangulation is a technique that involves writing 2 assertions to drive a safer creation of a more general implementation.

In the previous example, triangulation has been used in step 5 to force the creation of a more general solution in step 6.

Triangulation in Test-Driven Development

Now you might be asking yourself: why exactly 2 assertions are necessary and why a single assertion is not enough?

3. Example: things going wrong

Let's say I take an alternative approach at step 5. Without using the triangulation technique I go directly to refactor phase and throw a flawed generic solution.

Step 5: refactor (alternative)

Let's try the following generic solution:

javascript
export function sum(n) {
return n + 2
}

What I've done is just dump a simple but flawed generic solution. What's interesting, is that the unit test, the one defined in step 3 with 1 assertion... still passes!

javascript
import { sum } from './sum'
describe('sum()', () => {
it('should calculate sum', () => {
expect(sum(1, 2)).toBe(3)
})
})
PASS sum.spec.js
sum()
✓ should calculate sum (2 ms)

But having used the triangulation technique here, the flawed generic solution wouldn't have passed the unit test with 2 assertions:

javascript
import { sum } from './sum'
describe('sum()', () => {
it('should calculate sum', () => {
expect(sum(1, 2)).toBe(3)
expect(sum(3, 4)).toBe(7)
})
})
FAIL sum.spec.js
sum()
✕ should calculate sum (4 ms)
● sum() › should calculate sum
expect(received).toBe(expected) // Object.is equality
Expected: 7
Received: 5
4 | it('should calculate sum', () => {
5 | expect(sum(1, 2)).toBe(3)
> 6 | expect(sum(3, 4)).toBe(7)
| ^
7 | })
8 | })
9 |

4. Conclusion

I like the triangulation technique because it helps to create a generic implementation by reducing misses along the way.

You will find the technique useful when you're not sure about the correctness of the generic code you want to write. Having 2 assertions can give you more confidence.

In what scenarios do you find the triangulation technique useful?

Like the post? Please share!

Quality posts into your inbox

I regularly publish posts containing:

  • Important JavaScript concepts explained in simple words
  • Overview of new JavaScript features
  • How to use TypeScript and typing
  • Software design and good coding practices

Subscribe to my newsletter to get them right into your inbox.

Join 6719 other subscribers.
Dmitri Pavlutin

About Dmitri Pavlutin

Tech writer and coach. My daily routine consists of (but not limited to) drinking coffee, coding, writing, coaching, overcoming boredom 😉.

Quality posts into your inbox

I regularly publish posts containing:

  • Important JavaScript concepts explained in simple words
  • Overview of new JavaScript features
  • How to use TypeScript and typing
  • Software design and good coding practices

Subscribe to my newsletter to get them right into your inbox.

Join 6719 other subscribers.
Dmitri Pavlutin

About Dmitri Pavlutin

Tech writer and coach. My daily routine consists of (but not limited to) drinking coffee, coding, writing, coaching, overcoming boredom 😉.