2. –Edsger W. Dijkstra 1969
“Testing shows the presence,
not the absence of bugs”
2
3. What is a test?
• REQUIREMENT: The calculator adds two numbers
• VERIFICATION:
• Turn on the calculator
• Write 2
• Press the plus sign
• Write 4
• Press equal
• The display should show 6
3
4. What is a test?
test('add two numbers', () => {
let calculator = new Calculator();
calculator.input(2);
calculator.plus();
calculator.input(4);
calculator.equal();
let result = calculator.get();
expect(result).toBe(6);
});
4
6. What to test?
• How many cases has the addition case?
• Two 32 bit inputs
232 x 232 = 18.446.744.073.709.551.616 cases
• If it takes 1 ms each case, we need 600 milion years
6
7. What to test?
• Which cases are relevant?
• The ones defined by requirements
• The minimal ones possible
• The most relevant ones
• The most easy to understand by a human
7
8. Why test?
// 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])
8
Before testing was
mainstream academia
tried verification. It was
not useful enough.
9. Why test?
• Were we loose the time when we are developing?
9
+- +-
Think Write Debug
+-
Think carefule before go to
the next slide. Which one
is the one in which you
invest more time?
10. Why test?
• The reality.
10
+- +-
Think Write Debug
+-
Think again (probably). If you do
not do testing you loose a looot
of time of debugging. There is no
proud on debugging skills, they
are useless when doing testing.
And writing, is so fast.
11. Why test?
• Our objective.
11
+- +-
Think Write Debug
+-
Testing first means think
more and caching bugs
earlier. Caching bugs
earlier means less debug.
12. Why to test?
• We know for sure that each scenario is working.
• 2 + 4 = [6]
• 2 + 4 + 5 = [11]
• 2 x 4 = [8]
• 2 x 4 x 5 = [40]
• 2 + 3 x 4 = [14]
• ...
12
13. Why to test?
• Trust
13
There is a button that
when I press it, I know that
everything works.
14. Why to test?
• Speed
14
Without Testing With Testing
Testing/TDD seems slow in
the beginning, but it is an
illusion, test nothing is
quickly more time-
consuming.
15. Why to test?
• Better design
15
Because we are confident
in changes, we can
upgrade the design under
demand. We do not need
to advance unnecessary
design complexity.
16. Why Testing?
• Automatic requirement/business rules verification
• Reduce debug time
• You know that every scenario works
• Trust
• Speed
• Better design
• LIVE DOCUMENTATION
16
And of course, tests are
documentation that never
stale.
18. 18
“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
Early History of Testing
19. 19
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
Modern History of Testing
20. 20
In 2002, fit, Framework
Integrated Test, was able to
execute tests from actual
documentation.
22. Summary
• Testing does not ensure the absence of bugs
• Tests are driven by requirments and business rules
• Only test what is relevant, not everything
• Tests Improves quality and confidence
• It is live documentation
• Test is not new, and some great advances have 2 decades
22