ES3-2020-06 Test Driven Development (TDD)

06 Testing - TDD
Enginyeria del Software 3
1
@drpicox — 2020

Accounting
• Accounting is a discipline that is in charge of studying,
measuring and analyzing the assets and ﬁnancial and
economic situation of a company or organization, in order
to facilitate decision-making within it and external control,
presenting the information , previously registered, in a
systematic and useful way for the diﬀerent interested
parties. 
 
—Wikipedia
2

Double-entry bookkeping
• At least two accounting entries are required to record
each ﬁnancial transaction: debit and credit.
3

–Merriam-Webster dictionary
“Discipline: training that corrects, molds, or
perfects the mental faculties or moral character”
4

Test Development Driven
• The Three rules of TDD: 
1. You are not allowed to write any production code unless it is
to make a failing unit test pass. 
2. You are not allowed to write any more of a unit test than is
suﬃcient to fail; and compilation failures are failures. 
3. You are not allowed to write any more production code than
is suﬃcient to pass the one failing unit test.
5
http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Stages of TDD
6
RED
GREEN
REFACTOR
TEST CODE
CLEAN
Write production code
until tests pass.
Write tests
until a test fails.
Clean code while tests passes.
Clean tests while tests passes.
Clean ...
...
YOU
START
HERE
30s
loop

Common Pitfalls (1/2)
• Typical individual mistakes include:

• forgetting to run tests frequently,

• writing too many tests at once,

• writing tests that are too large or coarse-grained,

• writing overly trivial tests, for instance omitting assertions,

• writing tests for trivial code, for instance accessors.
7

Common Pitfalls (2/2)
• Typical team mistakes include:

• partial adoption: only a few developers on the team use TDD,

• poor maintenance of the test suite: most commonly leading to a
test suite with a prohibitively long running time,

• abandoned test suite (i.e. seldom or never run): sometimes as a
result of poor maintenance, sometimes as a result of team
turnover.
8

London vs Chicago TDD
• London School of TDD: Mockists

• use spies to verify implementation

• higher coupling

• Chicago School of TDD: Statists

• depend on results, not on imlpementation details

• our objective
9

London Example
import { add } from "math"
import multiply from "./multiply"
let log
function addMock(a, b) {
log.push(`${a}+${b}`)
return add(a, b)
}
test("multiplies two numbers", () => {
log = []
const result = multiply(3, 4, { add: addMock })
expect(log).toEqual("0+3", "3+3", "6+3", "9+3")
expect(result).toEqual(12)
})
10

Chicago Example
import multiply from "./multiply"
test("multiplies two numbers", () => {
const result = multiply(3, 4)
expect(result).toEqual(12)
})
11

Craftsman Recipe
• You already know how to create tests and do TDD

• Probably you already do some kind of TDD manually

• You just need to write it ﬁrst

• There are 5 steps to help you
12

Step 1: First tests
• Write ﬁrst the test that gives you the excuse for writing
the ﬁrst code.
13
test("create a game", () => {
const game = new Game()
})
class Game {}

Step 2: Progressing
• You already test manually things before and after code

• Write the test code that test that for you
14

Step 2: Progressing
// 1: I want to check that I can add the search box
test("There is a search box", () => {
const searchBox = getByPlaceholderText(
container,
"search"
)
expect(searchBox).toBeInTheDocument()
})
15

Step 2: Progressing
// 2: I want to check that I can write in the text box
test("The search box accepts text", () => {
container,
"search"
)
userEvent.type(searchBox, "apollo x")
expect(searchBox).toHaveAttribute("value", "apollo x")
})
16

Step 2: Progressing
// 3: I want to check that I have a search button
test('There is a search button', () => {
const searchButton = getByText(container, 'search')
expect(searchButton).toBeInTheDocument()
})
17

Step 2: Progressing
// 4: I want to know that clicking in search triggers fetch
test("The search button makes a fetch from the service",
async () => {
container,
"search"
)
const searchButton = getByText(container, "search")
searchButton.click()
await fetchMock.expectGET("/api/v1/search?q=apollo%20x")
})
18

Step 2: Progressing
// 5: I want to know if there is the response area
test("There is a response area after doing a search", async () => {
container,
"search"
)
await fetchMock
.whenGET("/api/v1/search?q=apollo%20x")
.respond(["snoopy and charlie brown"])
const resultArea = await findByTestId(
container,
"search-response"
)
expect(resultArea).toBeInTheDocument()
})
19

Step 2: Progressing
// 6: I want to check that results are in the response area
test("The search result is shown in the response area", async () => {
const searchBox = getByPlaceholderText(container, "search")
await fetchMock
const resultArea = await findByTestId(
container,
"search-response"
)
expect(resultArea).toHaveTextContent(
"snoopy and charlie brown"
)
})
20

Step 3: Remove UI use
• Make test express your intention, not how to use the UI

• Protect your tests from the UI changes
21

• Make test express your intention, not how to use the UI

• Protect your tests from the UI changes
22

import { search, findSearchResult } from "./__helpers__/ui.js"
test("The search result is shown in the response area",
async () => {
search(container, "apollo x")
await fetchMock
const resultArea = await findSearchResult(container)
)
})
23

import { search, findSearchResult } from "./__helpers__/ui.js"
async () => {
search(container, "apollo x")
await fetchMock
const resultArea = await findSearchResult(container)
)
})
24

// __helpers__/ui.js
export function search(container, text) {
container,
"search"
)
userEvent.type(searchBox, text)
}
export async function findSearchResult(container) {
const results = await findByTestId(
container,
"search-result"
)
return results
}
25

Step 4: Refactor
• Make test and code easy to read and understand
26
import { search } from "./__helpers__/ui.js"
import {
theSearchServiceFor
} from "./__helpers__/searchService.js"
async () => {
theSearchServiceFor("apollo%20x").respond([
"snoopy and charlie brown",
])
const resultArea = search(container, "apollo x")
)
})

Step 5: Business value
• All tests should directly express requirements
27
import { search } from "./__helpers__/ui.js"
import { theSearchServiceFor } from "./__helpers__/searchService.js"
// removed test('There is a search box', () => {
// removed test('The search box accepts text', () => {
// removed test('There is a search button', () => {
// removed test('The search button makes a fetch from the service',...
test("Search for the LEM and Module name", async () => {
theSearchServiceFor("apollo%20x").respond([
"snoopy and charlie brown",
])
const resultArea = search(container, "apollo x")
)
})

Bonus Step: Use tables
• Refactor your test to accommodate tables
28
test.each`
text | query | response | result
${"unknown"} | ${"unknown"} | ${[]} | ${"no results"}
${"apollo"} | ${"apollo"} | ${["snoopy", "eagle"]} | ${"snoopyeagle"}
${"apollo x"} | ${"apollo%20x"} | ${["snoopy"]} | ${"snoopy"}
${"apollo x module:command"} | ${"apollo%20x&module=command"} | ${["charlie brown"]} | ${"charlie brown"}
${"module:command"} | ${"&module=command"} | ${["charlie", "columbia"]} | ${"charliecolumbia"}
`(
'Search for the LEM and module name of "$text"',
async ({ text, query, response, result }) => {
theSearchServiceFor(query).respond(response)
const resultArea = search(container, text)
expect(resultArea).toHaveTextContent(result)
}
)

Refactors
• Big Refactors

• Small Refactors
29

Big Refactors
• Programmers always want to throw
away the code and start over

• They think the old code is a mess

• They are probably wrong.
30
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
by Joel Spolsky
It’s harder to read code than to write it.

Small Refactors
• Leverage on Tests: small change, test, small change, test, ...

• Clean the code and adjust the architecture, slowly and ﬁrmly
31
REFACTOR
CLEAN

Small Refactors
• Find a path for small changes

• Recipe for representation changes:

1. Add the structure representation → Test

2. Add a setter code → Test

3. Repeat 2. until no more setters

4. Moddify a getter code → Test

5. Repeat 4. until no more getters

6. Clean a getter code → Test & Repeat

7. Clean a setter code → Test & Repeat

8. Remove old representation → Test
32

Example (BGK)
export default class Game {
_score = 0;
roll(pins) {
this._score += pins;
}
score() {
return this._score;
}
}
33

Example (BGK)
_score = 0;
_rolls = [];
roll(pins) {
}
score() {
return this._score;
}
}
34
Step 1: new representation

Example (BGK)
_score = 0;
_rolls = [];
roll(pins) {
this._rolls.push(pins);
}
score() {
return this._score;
}
}
35
Step 2: setters

Example (BGK)
_score = 0;
_rolls = [];
roll(pins) {
}
score() {
let score = 0;
for (let i = 0; i < this._rolls.length; i++) {
score += this._rolls[i];
}
return score;
}
}
36
Step 4: getters

Example (BGK)
_score = 0;
_rolls = [];
roll(pins) {
}
score() {
let score = 0;
}
return score;
}
}
37
Step 7: clean setters

Example (BGK)
_score = 0;
_rolls = [];
roll(pins) {
}
score() {
let score = 0;
}
return score;
}
}
38
Step 8: clean old represent.

Example (BGK)
_score = 0;
roll(pins) {
}
score() {
let score = 0;
}
return score;
}
}
39
Done

Example (Pattern)
// Painter should draw a square
class Painter {
draw() {
drawSquare()
}
}
40

Example (Pattern)
// The square size may change
class Painter {
draw(size: number) {
drawSquare(size)
}
}
41

Example (Pattern)
// The painter can draw also circles with size
class Painter {
draw(shape: String, size: number) {
if (shape === "Circle") drawCircle(size)
else drawSquare(size)
}
}
42

Example (Pattern)
// The painter can draw also stars
class Painter {
if (shape === "Star") drawStar(size)
else if (shape === "Circle") drawCircle(size)
}
}
43
This is not right, too complex if/switch

Example (Pattern)
// The painter can draw also circles with size
class Painter {
if (shape === "circle") drawCircle(size)
}
}
44

Example (Pattern)
interface Shape {
draw(size: number);
}
class Painter {
}
}
45

Example (Pattern)
interface Shape { ... }
class Circle implements Shape {
drawCircle(size)
}
}
class Painter {
}
}
46

Example (Pattern)
class Circle implements Shape {
drawCircle(size)
}
}
class Painter {
if (shape === "circle") new Circle.draw(size)
}
}
47

Example (Pattern)
class Circle implements Shape { ... }
class Square implements Shape {
drawSquare(size)
}
}
class Painter {
}
}
48

Example (Pattern)
class Square implements Shape {
drawSquare(size)
}
}
class Painter {
else new Square.draw(size)
}
}
49

Example (Pattern)
class Square implements Shape { ... }
const shapes = {
circle: new Circle(),
square: new Square(),
};
class Painter {
else new Circle.draw(size)
}
}
50

Example (Pattern)
const shapes = { ... };
class Painter {
shapes[shape].draw(size)
}
}
51

Example (Pattern)
class Painter {
draw(shape: String = "square", size: number) {
shapes[shape].draw(size)
}
}
52

Example (Pattern)
class Star implements Shape {
draw(size) {}
}
class Painter {
shapes[shape].draw(size);
}
}
53

Example (Pattern)
draw(size) {}
}
const shapes = {
circle: new Circle(),
square: new Square(),
star: new Star(),
};
class Painter {
}
}
54

Example (Pattern)
draw(size) {
drawStar(size)
}
}
class Painter {
}
}
55

Small Refactors
• Step by Step

• Always Green
56

Homework
• https://www.agilealliance.org/glossary/acceptance

• https://www.agilealliance.org/glossary/unit-test

• https://wiki.c2.com/?ArrangeActAssert

• http://agileinaﬂash.blogspot.com/2009/02/ﬁrst.html
57

The Two Disks Parable
58
TESTS CODE

ES3-2020-06 Test Driven Development (TDD)

More Related Content

What's hot (20)

Similar to ES3-2020-06 Test Driven Development (TDD) (20)

More from David Rodenas (16)

Recently uploaded (20)

ES3-2020-06 Test Driven Development (TDD)