This talk cares about the fundamentals of testing, a little bit history of how the professional community developed what we currently know as testing, but also about why I should care about testing? why is it important to do a test? What is important to test? What is not important to test? How to do testing? There some examples in plnker just to see each step, and many surprises. This talk also compares what people learned in the Computer Sciences and Engineering degrees and what people does in testing. It gives some tips to catch up with current state of art and gives some points to start changing syllabus to make better engineers. This talk is good for beginners, teachers, bosses, but also for seasoned techies that just want to light up some of the ideas that they might have been hatching. Spoiler alert: testing will save you development time and make you a good professional.

1. (automatic) Testing
from business to university and back
David Ródenas — @drpicox

2. from business…

3. History

4. @drpicox 4
“The growth of Software Testing”- ACM June 1988 D.Gelperin, B.Hetzel
1957
1979
1983
1988
Debugging
Demonstration
Destruction
Evaluation
Prevention
mixing construction and debugging
making sure that software satisfies its specification
detecting implementation faults
detecting requirements, design & implementation faults
preventing requirements, design & implementation faults

5. @drpicox 5
“The growth of Software Testing”- ACM June 1988 D.Gelperin, B.Hetzel
“

6. @drpicox 6
http://wiki.c2.com/?TenYearsOfTestDrivenDevelopment
1994
1999
2002
Beginning of new Era
xUnit
Extreme Programming
Framework Integrated Test
Test Driven Development
Ward Cunningham writes in one day a test runner
Kent Beck writes first version of SUnit (Testing Framework)
“Extreme Programming Explained: Embrace Change” - Kent Beck
Ward Cunningham writes first tool for test running
“Test Driven Development By Example” - Kent Beck
1989

7. @drpicox
Testing Tools
• 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
7

8. @drpicox
Testing Tools
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);
});
…
});
8

9. @drpicox
Testing Tools
9
2,4,8 Rule Game
http://embed.plnkr.co/N0eGMg

10. Why testing?

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

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

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

14. @drpicox
Coding cost
14
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…

15. @drpicox
Coding cost
15
Debug
+-
¿How many debug cases
have you thrown away?

16. @drpicox
Coding cost
16
+- +-
Think Write Debug
+-

17. @drpicox
Coding cost
17
+- +-
Think Write Debug
+-

18. @drpicox
Coding cost
18
+- +-
Think Write Debug
+-

19. @drpicox
Why testing?
19

20. @drpicox
Why testing?
• Automatic testing saves time
• Considers all features with all semantics
• Everything is debugged
• Does not throw away debug cases
• New features does not break old one
• Safe refactors to accommodate new changes
• More bald implementations
• Developers(professionals) feel safer.
20

21. What to test?

22. @drpicox
Types of bugs
22
Logic Wiring Visual

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

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

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

26. @drpicox
Types of testing
26
Logic
Wiring
Visual
#tests
whole system
subsystems
just classes
each takes

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

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

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

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

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

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

33. @drpicox
Unit Test Everything!
• Test coverage?
33
¿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?

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

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

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

37. @drpicox
TDD Rules
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.
37
http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

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

39. …crossing to university

40. @drpicox
Verification
40
// Pre: 0 ≤ left ≤ right ≤ vec.length
function posMin(vec, left, right) {
let pos = left;
for (let i = left + 1; i <= right; i++) {
if (vec[i] < vec[pos]) pos = i;
}
return pos;
}
// Post: returns pos ∧
// ∧ left ≤ pos ≤ right ∧
// ∧ vec[pos] = min(vec[left … right])

41. @drpicox
Automatic Evaluation
41
$ cc my-solution.c -o my-solution
$ diff <(./my-solution < p1.in) p1.out
$ diff <(./my-solution < p2.in) p2.out
$ diff <(./my-solution < p3.in) p3.out
$ diff <(./my-solution < p4.in) p4.out
$ cp my-solution.c /home/subject/e/h8463827.c

42. @drpicox
Patterns
• Abstraction
factory
• Builder
• Factory method
• Prototype
• Singleton
• Adapter
• Bridge
42
• Composite
• Decorator
• Facade
• Proxy
• Chain of
responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template
method
• Visitor

43. @drpicox
Grasp
• Controller
• Creator
• High cohesion
• Indirection
• Expert
43
• Low coupling
• Polymorphism
• Protected variations
• Pure fabrications

44. @drpicox
Designs
44

45. what else should be there?

46. @drpicox
Hello World
46
describe(‘hello world’, () => {
it(‘it should say hi there!’, () => {
let helloWorld = new HelloWorld();
helloWorld.sayHello();
expect(???).toBe(‘hi there!’);
});
});
http://embed.plnkr.co/JxAOX7

47. ban
Singletons

48. ban
Singletons
Seriously
no buts
they lie
they
are evil
ARE GLOBALS!
i’ll got
zero in 1st course
if I've used them
also ban
class members

49. ban
Singletons
Seriously
no buts
they lie
they
are evil
ARE GLOBALS!
use singletons instead
(^ yes, lowercased s)
i’ll got
zero in 1st course
if I've used them
also statics

50. @drpicox
Dependency Injection
function testCreditCardCharge() {
CreditCard c = new CreditCard(
"1234 5678 9012 3456", 5, 2008);
c.charge(100);
}
50
It gives as result: NullPointerException

51. @drpicox
Dependency Injection
function testCreditCardCharge() {
Database.init();
CreditCardProcessor.init();
OfflineQueue.init();
CreditCard c = new CreditCard(
"1234 5678 9012 3456", 5, 2008);
c.charge(100);
}
51
It works… but you loose 100$

52. @drpicox
Dependency Injection
function testCreditCardCharge() {
Database db = new Database();
OfflineQueue q = new OfflineQueue(db);
CreditCardProcessor ccp =
new CreditCardProcessor(q);
CreditCard c = new CreditCard(
"1234 5678 9012 3456", 5, 2008);
c.charge(ccp, 100);
}
52
Looks better, right? But you still loosing 100$.

53. @drpicox
Dependency Injection
function testCreditCardCharge() {
CreditCardProcessorMock ccp =
new CreditCardProcessorMock();
CreditCard c = new CreditCard(
"1234 5678 9012 3456", 5, 2008);
c.charge(ccp, 100);
assertTrue(ccp
.charged("1234 5678 9012 3456", 100));
}
53
Looks better!

54. @drpicox
Dependency Injection
• Is inversion of control for resolving dependencies.
• Your dependencies will explicitly be:
• given by constructor
• setted after construction
54
class UserController {
constructor(userService) {
this.userService = userService;
}
}

55. @drpicox
Dependency Injection
55
Two piles
Pile of Objects
• Business logic
• This is why you write code
Pile of New Keywords
• Factories, Providers, …
• Build object graphs
• This is how you get the
code you write to work
together
new
new
new
new
new
new
new
new
new
new
new

56. @drpicox
Dependency Injection
56
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

57. @drpicox
Law of Demeter
• You only ask for objects which you directly need (operate
on)
• a.getX().getY()… is dead giveaway
• serviceLocator.getService() is breaking the Law of
Demeter
• Dependency Injection of the specific object you need.
Hollywood Principle.
57

58. …and back to business

59. @drpicox
How university can contribute?
• Write tests First!
• Create testing syllabus
• Get deeper in Cohesion
• Transmit: Professionalism require testing
59

60. @drpicox 60
Summary

61. @drpicox
Sumary
• Testing saves development time
• Focus in Unit Test
(acceptance testing is also amazing)
• Tests to show that your code is what you need
• Make dependencies explicit
61

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

63. @drpicox
Bibliography
63
• “The growth of Software Testing”- ACM June 1988 D.Gelperin, B.Hetzel
• http://wiki.c2.com/?TenYearsOfTestDrivenDevelopment
• 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/

64. @drpicox
Bibliography
64

65. @drpicox
Thanks!
65
David Ródenas — @drpicox