![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.](https://image.slidesharecdn.com/es3-2020-05-testing-201009114329/85/ES3-2020-05-Testing-8-320.jpg)
![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](https://image.slidesharecdn.com/es3-2020-05-testing-201009114329/85/ES3-2020-05-Testing-12-320.jpg)
ES3-2020-05 Testing
- 1. 05 Testing Enginyeria del Software 3 1 @drpicox — 2020
- 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
- 5. What to test? • The requirements, or business rules 5
- 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.
- 21. 21 Example of a table executed by Test.
- 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