Embed Size (px)
Citation preview
(automatic) Testing from business to university and back
David Ródenas — @drpicox
from business…
History
@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
@drpicox 5
“The growth of Software Testing” - ACM June 1988 D.Gelperin, B.Hetzel“
@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
@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
@drpicox
Testing Toolsdescribe(‘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
Why testing?
@drpicox
Coding cost
11
+- +-
Think Write Debug+-
@drpicox
Coding cost
12
Think+-
• Surrounding code
• API for the new code
• Understand new features
@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
@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…
@drpicox
Coding cost
15
Debug+-
¿How many debug cases have you thrown away?
@drpicox
Coding cost
16
+- +-
Think Write Debug+-
@drpicox
Coding cost
17
+- +-
Think Write Debug+-
@drpicox
Coding cost
18
+- +-
Think Write Debug+-
@drpicox
Why testing?
19
@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
What to test?
@drpicox
Types of bugs
22
Logic Wiring Visual
@drpicox
Types of bugs
23
Logic Wiring VisualDetection
Diagnose
Correction
@drpicox
Types of bugs
24
Logic Wiring VisualDetection HARD EASY TRIVIAL
Diagnose HARD MEDIUM EASY
Correction HARD MEDIUM EASY
@drpicox
Detection HARD MEDIUM EASY
Diagnose HARD MEDIUM EASY
Correction HARD MEDIUM EASY
Types of bugs
25
Logic Wiring VisualIt is hard!
Is it?
@drpicox
Types of testing
26
Logic
Wiring
Visual#tests
whole system
subsystems
just classes
each takes
@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
@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
@drpicox
Types of testing
29
Logic
Wiring
Visualwhole system
subsystems
just classesUnit
End- -to-End
Functional
Soft
war
e En
gine
ers
QA
Engi
neer
s
@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
@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
@drpicox
Unit Test Everything!• Test coverage?
32
@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?
@drpicox
Unit Test Everything!
34
Serious Bankinghttp://embed.plnkr.co/veOMnl
🃏
@drpicox
Unit Test Everything?
35
Serious Bankinghttp://embed.plnkr.co/veOMnl
🃏
Sorry, not everything, we have frame problem. (we can imagine infinite stupid things that can go wrong)
@drpicox
TDD Rules
36
• Has anyone tried to write tests after write the code?
@drpicox
TDD Rules1. 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
@drpicox
TDD Rules
38
• You can see it in the following Kata:
• The Bowling Game Kata
…crossing to university
@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])
@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
@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
@drpicox
Grasp• Controller
• Creator
• High cohesion
• Indirection
• Expert
43
• Low coupling
• Polymorphism
• Protected variations
• Pure fabrications
@drpicox
Designs
44
what else should be there?
@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
ban Singletons
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
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
@drpicox
Dependency Injectionfunction testCreditCardCharge() { CreditCard c = new CreditCard( "1234 5678 9012 3456", 5, 2008); c.charge(100); }
50
It gives as result: NullPointerException
@drpicox
Dependency Injectionfunction 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$
@drpicox
Dependency Injectionfunction 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$.
@drpicox
Dependency Injectionfunction 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!
@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; } }
@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
newnew
new
new
newnew
@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
@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
…and back to business
@drpicox
How university can contribute?• Write tests First!
• Create testing syllabus
• Get deeper in Cohesion
• Transmit: Professionalism require testing
59
@drpicox 60
Summary
@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
@drpicox
Sumary• and of course:
62
Write tests First!
@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/
@drpicox
Bibliography
64
@drpicox
Thanks!
65
David Ródenas — @drpicox
