testing 101
TRANSCRIPT
![Page 1: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/1.jpg)
TESTINGI FIND YOUR LACK OF TESTS
DISTURBING
![Page 2: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/2.jpg)
WHAT IS TESTING? YOU SAY WHILE YOU NAIL IN MY PUPIL YOUR PUPIL IN BLUE. WHAT IS TESTING? AND YOU ASK TO ME? TESTING… IS YOU.
To the unknown developer…
INTRO
![Page 3: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/3.jpg)
INTRO
1. The Dark Side
2. Padawan’s path
3. Use the Tests
4. Test practices
![Page 4: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/4.jpg)
THE DARK SIDE
![Page 5: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/5.jpg)
THE DARK SIDE
▸Companies
▸Want to reduce costs
▸Saving time -> reducing plans
▸Saving money -> reducing salaries
▸Developers
▸feel pressured and don’t have time to test
▸don’t want to test or to learn how to test
▸I’m not going to talk about salaries so let’s talk about technical things
![Page 6: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/6.jpg)
LIFECYCLE MANAGEMENT
![Page 7: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/7.jpg)
WATERFALLLIFECYCLE
![Page 8: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/8.jpg)
SOFTWARE LIFECYCLE MANAGEMENT
WATERFALL: A TRADITIONAL ENGINEERING APPROACHREQUIREMENTS
ANALYSIS
SOFTWARE DESIGN
IMPLEMENTATION
TESTING
INTEGRATION
DEPLOYMENT
MAINTENANCEhttps://en.wikipedia.org/wiki/Software_development_process
DOCUMENT IT !!
![Page 9: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/9.jpg)
V-MODELLIFECYCLE
![Page 10: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/10.jpg)
SOFTWARE LIFECYCLE MANAGEMENT
V-MODEL: AN EXTENDED WATERFALL
REQUIREMENTS ANALYSIS
SYSTEM DESIGN
IMPLEMENTATION
INTEGRATION
VALIDATION
MAINTENANCECONCEPTS OF OPERATIONS
INTEGRATION
VALIDATION
MAINTENANCE
TESTIN
G
UNIT
INTEGRATION
FUNCTIONAL
https://en.wikipedia.org/wiki/V-Model_(software_development)
TIMELINE
![Page 11: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/11.jpg)
SPIRALLIFECYCLE
![Page 12: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/12.jpg)
SOFTWARE LIFECYCLE MANAGEMENT
SPIRAL: CYCLES OF MINI-WATERFALLS
SOFTWARE DESIGN
CODE
TESTING
INTEGRATION
IMPLEMENTATION
OBJECTIVES RISKS
PLAN
https://en.wikipedia.org/wiki/Software_development_process
![Page 13: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/13.jpg)
AGILELIFECYCLE
![Page 14: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/14.jpg)
SOFTWARE LIFECYCLE MANAGEMENT
AGILE MANIFESTO
▸Based on 12 principles
▸ Individuals and interactions
▸Working Software
▸Customer collaboration
▸Responding to change
![Page 15: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/15.jpg)
SOFTWARE LIFECYCLE MANAGEMENT
AGILE MANIFESTO
▸Working software is the principal measure of progress
▸Welcome changing requirements, even in late development
▸Continuous attention to technical excellence and good design
![Page 16: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/16.jpg)
SOFTWARE LIFECYCLE MANAGEMENT
AGILE MANIFESTO
▸Working software: How do you assert that?
▸Changing requirements: How do you verify you don’t break existing things?
▸Good design: Are you able to easily test it?
![Page 17: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/17.jpg)
PADAWAN’S PATH
![Page 18: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/18.jpg)
PADAWAN’S PATH
▸Include Testing activities the soonest
▸Developers HAVE TO write tests
▸Do not treat QA as the next team in the line
![Page 19: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/19.jpg)
TEST EARLIER AND MORE
BEST PRACTICE 1
![Page 20: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/20.jpg)
PADAWAN’S PATH: WRITE TESTS EARLIER
▸Removes fear of changes
▸Executable examples/documentation
▸Enables refactoring
▸Helps you understand design
▸It’s not slower: faster and more robust
▸Visual feedback: red & green
![Page 21: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/21.jpg)
DEVELOPERS WRITE TESTS
BEST PRACTICE 2
![Page 22: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/22.jpg)
▸Unit, Integration and functional tests
▸Do not fall in the fallacy of automate everything: Automate critical things
▸This is not removing QA team: they automate things and specialise in Exploratory Testing
PADAWAN’S PATH: DEVELOPERS WRITE TESTS
![Page 23: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/23.jpg)
TREAT QA NOT AS “THE QA GUYS”
BEST PRACTICE 3
![Page 24: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/24.jpg)
http://sauceio.com/wp-content/uploads/2016/08/blog-post-600x451.png
![Page 25: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/25.jpg)
▸Otherwise, QA finds bugs when it’s expensive
▸QA are team members
▸Spread the knowledge with them: involve them in daily meetings, demos…
▸Result? Enables Exploratory Testing
PADAWAN’S PATH: THE IMPORTANCE OF QA TEAM
![Page 26: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/26.jpg)
USE THE TESTS
![Page 27: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/27.jpg)
UNITTEST TYPES
![Page 28: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/28.jpg)
UNIT TESTS
▸Isolated code
▸Executed fast
▸Always automated
▸I.e.: utility classes, POJO’s
▸Book: “Effective Unit Testing” Lasse Koskela
![Page 29: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/29.jpg)
UNIT TESTS: MOCKS
▸Mocks
▸Isolate code
▸Speed up test execution
▸Simulate special conditions
![Page 30: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/30.jpg)
UNIT TESTS: MOCKS
▸Stub: objects which return a specific value.
▸Fake Object: simpler than real implementation but more elaborated than a stub.
▸Spy Object: registers what is being executed in a test.
▸Mock: a more powerful spy object.
![Page 31: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/31.jpg)
UNIT TESTS: MOCKS
▸Mocks
▸Increase complexity/maintainability
▸Careful with wrong behaviour
▸Too much expectations
▸Corporate mocks
![Page 32: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/32.jpg)
INTEGRATIONTEST TYPES
![Page 33: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/33.jpg)
INTEGRATION TESTS
▸Code depending on other (module, component, service…)
▸Not executed that fast
▸I.e. database, file system, modules..
![Page 34: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/34.jpg)
END-TO-ENDTEST TYPES
![Page 35: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/35.jpg)
END-TO-END TESTS: PROS
▸Loved by management
▸Simulates user behaviour
▸Black-box testing
![Page 36: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/36.jpg)
END-TO-END TESTS: DRAWBACKS
▸Difficult root cause analysis
▸Small errors can hide real problems
▸Slow execution
▸Report bugs that could have been fixed before
▸Super hard maintenance
![Page 37: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/37.jpg)
MANUAL TESTS
UI TESTS
INTEGRATION
UNIT
![Page 38: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/38.jpg)
MANUAL TESTS
UI TESTS
INTEGRATION
UNIT70%
20%
10%
![Page 39: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/39.jpg)
SMOKETEST TYPES
![Page 40: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/40.jpg)
SMOKE TESTS
▸Define critical paths on your end-to-end tests
▸Execute it as a minimal proof of working software
▸Always automated
![Page 41: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/41.jpg)
EXPLORATORYTEST TYPES
![Page 42: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/42.jpg)
EXPLORATORY TESTING
▸You need knowledge of the system
▸Knowledge increases while you test
▸It’s not automated
▸Relay on human experience and knowledge
▸Use test methods
▸Book: “Explore it!” E.Hendrickson
![Page 43: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/43.jpg)
PERFORMANCETESTING TYPES
![Page 44: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/44.jpg)
PERFORMANCE
▸Stress or capacity testing
▸Physically separated machines
▸A typical configuration:
▸Injector, Database, Application, Console
▸Very hard or specialised
▸Periodically executed
▸Tools: jMeter, Grinder, LoadRunner
![Page 45: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/45.jpg)
OTHER TESTSTESTING TYPES
![Page 46: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/46.jpg)
OTHER TESTS
▸Behaviour (BDD)
▸Usability
▸Security
▸Comparison
▸Alpha/Beta
▸…
![Page 47: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/47.jpg)
TEST PRACTICES
![Page 48: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/48.jpg)
TEST PRACTICES
▸A @Test should have only one reason to fail
▸A @Test should check just one thing
▸A good commentary explains why, not what
![Page 49: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/49.jpg)
TEST PRACTICES
▸Avoid conditional logic in tests
▸A constantly falling @Test is useless
▸A @Test that cannot fail has no value (false sense of security)
▸A @Test promising more than it delivers is untrustworthy
![Page 50: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/50.jpg)
UNTRUSTWORTHY TESTS
// does not test anything
public void testFoo() {
MyStaticClass.foo();
}
// does not do anything
public void testFoo() {
//new MyClass().foo()
}
// promise much more than expected
public void testSendEmailAfterLogin() {
new MyClass().foo()
}
![Page 51: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/51.jpg)
TEST PRACTICES
▸Write platform independent tests
▸Flaky tests that fail intermittently as usually related to I/O
▸Do not hardcode test-dependencies
▸Delete/close resources in @Before/@After methods
![Page 52: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/52.jpg)
PREMATURE OPTIMISATION AND DUPLICATION ARE THE ROOT OF ALL EVIL
Lasse Koskela. “Effective Unit Testing”
TEST PRACTICES
![Page 53: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/53.jpg)
DUPLICATION IN TESTS COULD BE GOOD IN FAVOUR OF IMPROVED READABILITY
Lasse Koskela. “Effective Unit Testing”
TEST PRACTICES
![Page 54: Testing 101](https://reader031.vdocuments.net/reader031/viewer/2022030315/587af9171a28ab93488b4e4b/html5/thumbnails/54.jpg)
MAY THE TEST BE WITH YOU