There are lots of talks about testing: they talk about syntax, methodologies, tools. But there is usually a missing point: Why it is important to do a test? What is important to test? What is not important to test? How to do testing? There lots of examples in plnker just to see each step, and many surprises. This talk is good for beginners, but also for some seasoned people that just want to light up some of the ideas that they might have been hatching. Spoiler alert: testing will save you development time.

1. Testing: ¿what, how, why?
David Ródenas — @drpicox

2. @drpicox
What?
describe(‘calculator’, () => {
it(‘should do sums’, () => {
let calculator = new Calculator();
calculator.input(2);
calculator.plus();
calculator.input(4);
calculator.equal();
let result = calculator.get();
expect(result).toBe(6);
});
});
2

3. @drpicox
How?
• NUnit, MSTest, …— C#
• FUnit, FRUIT, FortUnit, …— Fortran
• JUnit, FitNesse, Mockito, …— Java
• Jasmine, Mocha, QUnit, …— Javascript
• Unittest, py.test, Nose, …— Python
• MiniTest, Test::Unit, RSpec, … — Ruby
• …
• Cucumber, Selenium, SpecFlow, …— Scenario
3

4. • What?
• How?
• Why?

5. why?

6. @drpicox
Weight cost
6
+- +-
Think Write Debug
+-

7. @drpicox
Weight cost
7
Think
+-
• Surrounding code
• API for the new code
• Understand new features

8. @drpicox
Weight cost
8
Write
+-
• Faster typist speed is: 150 wpm
• Moderate typist speed is: 35 wpm
• 400 line code may contain 1000
words ~ 30 minutes

9. @drpicox
Weight cost
9
Debug
+-
• Even if everything works well, we
have to verify that it is true
• Navigate to affected point
• Make sure that everything works
as expected, each time
• If it fails, stop and start looking for
problems…

10. @drpicox
Weight cost
10
+- +-
Think Write Debug
+-

11. @drpicox
Weight cost
11
+- +-
Think Write Debug
+-

12. @drpicox
Weight cost
12
+- +-
Think Write Debug
+-

13. @drpicox
Debug
• How many debug cases have you thrown away?
13

14. @drpicox
Think
• Would not it be great for thinking to give us the debug?
• All cases
• All features with all semantics
• Everything debugged
• Do not throw away debug cases
• New features does not break old one
• Safe refactors to accommodate new changes
14

15. what?

16. @drpicox
Types of bugs
16
Logic Wiring Visual

17. @drpicox
Types of bugs
17
Logic Wiring Visual
Detection
Diagnose
Correction

18. @drpicox
Types of bugs
18
Logic Wiring Visual
Detection HARD EASY TRIVIAL
Diagnose HARD MEDIUM EASY
Correction HARD MEDIUM EASY

19. @drpicox
Detection HARD MEDIUM EASY
Diagnose HARD MEDIUM EASY
Correction HARD MEDIUM EASY
Types of bugs
19
Logic Wiring Visual
It is hard!
Is it?

20. @drpicox
Types of testing
20
Logic
Wiring
Visual
each takes there are
whole system
subsystems
just classes

21. @drpicox
Types of testing
21
Logic
Wiring
Visual > 10s
< 1s
~1ms
each takes
few
many
lots
there are
end-to-end
functional
unit
known as
whole system
subsystems
just classes

22. @drpicox
Types of testing
22
Logic
Wiring
Visual > 10s
< 1s
~1ms
each takes
few
many
lots
there are
end-to-end
functional
unit
known as
whole system
subsystems
just classes
acceptance testing
bdd
tdd

23. @drpicox
Types of testing
23
Logic
Wiring
Visual > 10s
< 1s
~1ms
each takes
few
many
lots
there are
end-to-end
functional
unit
known as
whole system
subsystems
just classes
acceptance testing
bdd
tdd

24. @drpicox
Types of testing
24
Logic
Wiring
Visualwhole system
subsystems
just classes
Unit
End-
-to-End
Functional
SoftwareEngineers
QAEngineers

25. @drpicox
Unit Testing
• It test the most dangerous kind of bugs
• It is easy to write
• It is fast to execute
• It is from engineers to engineers
• It focus into features details
25

26. @drpicox
Unit Testing
• It test the most dangerous kind of bugs → Solves them
• It is easy to write → Write tens in few minutes
• It is fast to execute → Development cycle of seconds
• It is from engineers to engineers → It is the doc
• It focus into features details → Solve fast ambiguity
• IT IS THE MOST POWERFUL TYPE OF TESTING
26

27. @drpicox
Unit Test Everything!
27
2,4,8 Rule Game
http://embed.plnkr.co/N0eGMg

28. @drpicox
Unit Test Everything!
• Test coverage?
28

29. @drpicox
Unit Test Everything!
• Test coverage?
29
¿Are you sure that you want
to write a line of code that cannot be
justified with a test?
¿Do you want to
write useless code?
¿Do you want to
maintain more code
than necessary?
¿Do you want to
relay in your ability
to manual testing
all cases?

30. @drpicox
Unit Test Everything!
30
Serious Banking
http://embed.plnkr.co/veOMnl
🃏

31. @drpicox
Unit Test Everything?
31
Serious Banking
http://embed.plnkr.co/veOMnl
🃏
Sorry, not everything, we have frame problem.
(we can imagine infinite stupid things that can go wrong)

32. how?

33. @drpicox
TDD
33
• Has anyone tried to write tests after write the code?

34. @drpicox 34
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 sufficient to fail; and compilation failures are
failures.
3. You are not allowed to write any more production code
than is sufficient to pass the one failing unit test.
Rules
http://embed.plnkr.co/x4yKnp
TDD

35. @drpicox
TDD
35
• You can see it in the following Kata:
• The Bowling Game Kata

36. @drpicox
it(‘should…’)
36
• No side effects: for each test instantiate the whole
system
• Fast execution: you should instantiate only what you
need
• Repeatable: test must always give same results

37. @drpicox
new
37
Carnew
Engine
BrakesWheels
Doors
…new
new
• In this schema, each time that we need a car, it makes a
new instance of all its parts, even if we do not need
them.
~tens of instances

38. @drpicox
new
38
Workshopnew
Garage
Cars
Staff
…new
new
• What if we are working with a higher level?
…
~thousands of instances

39. @drpicox
new
39
new
Garages
…
new
new
• Or even higher?
~zillions of instances
Franchises
Holding

40. @drpicox
new
40
• Dependency injection to the rescue (I)
describe(‘car’, () => {
it(‘lock should lock doors’, () => {
let doors = new Doors();
let car = new Car(null, null, doors);
car.lock();
expect(car.canOpenDoors()).toBe(false);
});
});

41. @drpicox
new
41
• Dependency injection to the rescue (II)
describe(‘hello world’, () => {
it(‘it should say hi there!’, () => {
let helloWorld = new HelloWorld();
helloWorld.sayHello();
expect(???).toBe(‘hi there!’);
});
});
http://embed.plnkr.co/JxAOX7

42. @drpicox
new
42
• Dependency injection to the rescue (II)
describe(‘hello world’, () => {
it(‘it should say hi there!’, () => {
let console = jasmine.createSpyObj(‘console’, [‘log’]);
let helloWorld = new HelloWorld(console);
helloWorld.sayHello();
expect(console.log).toHaveBeenCalledWith(‘hi there!’);
});
});
http://embed.plnkr.co/vZyo7u

43. @drpicox 43
Summary

44. @drpicox
Sumary
• Testing helps you to understand better what you want to
encode
• Testing saves you from throwing tests away and from
precious debug time
• Focus in Unit Test (acceptance testing is also amazing)
• Do not try to test every case that you can imagine
• Make sure that all tests explains your code
44

45. @drpicox
Sumary
• and of course:
45
Write tests First!

46. @drpicox
Bibliography
46
• https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
• https://www.amazon.com/Clean-Coder-Conduct-Professional-Programmers/dp/0137081073
• http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
• http://butunclebob.com/ArticleS.UncleBob.SingletonVsJustCreateOne
• http://misko.hevery.com/2008/11/17/unified-theory-of-bugs/
• http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
• http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
• http://misko.hevery.com/code-reviewers-guide/
• http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing
• http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/
• http://butunclebob.com/
• http://misko.hevery.com/
• plnkr.co/users/drpicox

47. @drpicox
Bibliography
47

48. @drpicox
Thanks!
48
David Ródenas — @drpicox
Testing: ¿what, how, why?