TESTINGI FIND YOUR LACK OF TESTS

DISTURBING

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

INTRO

1. The Dark Side

2. Padawan’s path

3. Use the Tests

4. Test practices

THE DARK SIDE

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

LIFECYCLE MANAGEMENT

WATERFALLLIFECYCLE

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 !!

V-MODELLIFECYCLE

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

SPIRALLIFECYCLE

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

AGILELIFECYCLE

SOFTWARE LIFECYCLE MANAGEMENT

AGILE MANIFESTO

▸Based on 12 principles

▸ Individuals and interactions

▸Working Software

▸Customer collaboration

▸Responding to change

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

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?

PADAWAN’S PATH

PADAWAN’S PATH

▸Include Testing activities the soonest

▸Developers HAVE TO write tests

▸Do not treat QA as the next team in the line

TEST EARLIER AND MORE

BEST PRACTICE 1

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

DEVELOPERS WRITE TESTS

BEST PRACTICE 2

▸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

TREAT QA NOT AS “THE QA GUYS”

BEST PRACTICE 3

http://sauceio.com/wp-content/uploads/2016/08/blog-post-600x451.png

▸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

USE THE TESTS

UNITTEST TYPES

UNIT TESTS

▸Isolated code

▸Executed fast

▸Always automated

▸I.e.: utility classes, POJO’s

▸Book: “Effective Unit Testing” Lasse Koskela

UNIT TESTS: MOCKS

▸Mocks

▸Isolate code

▸Speed up test execution

▸Simulate special conditions

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.

UNIT TESTS: MOCKS

▸Mocks

▸Increase complexity/maintainability

▸Careful with wrong behaviour

▸Too much expectations

▸Corporate mocks

INTEGRATIONTEST TYPES

INTEGRATION TESTS

▸Code depending on other (module, component, service…)

▸Not executed that fast

▸I.e. database, file system, modules..

END-TO-ENDTEST TYPES

END-TO-END TESTS: PROS

▸Loved by management

▸Simulates user behaviour

▸Black-box testing

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

MANUAL TESTS

UI TESTS

INTEGRATION

UNIT

MANUAL TESTS

UI TESTS

INTEGRATION

UNIT70%

20%

10%

SMOKETEST TYPES

SMOKE TESTS

▸Define critical paths on your end-to-end tests

▸Execute it as a minimal proof of working software

▸Always automated

EXPLORATORYTEST TYPES

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

PERFORMANCETESTING TYPES

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

OTHER TESTSTESTING TYPES

OTHER TESTS

▸Behaviour (BDD)

▸Usability

▸Security

▸Comparison

▸Alpha/Beta

▸…

TEST PRACTICES

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

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

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()

}

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

PREMATURE OPTIMISATION AND DUPLICATION ARE THE ROOT OF ALL EVIL

Lasse Koskela. “Effective Unit Testing”

TEST PRACTICES

DUPLICATION IN TESTS COULD BE GOOD IN FAVOUR OF IMPROVED READABILITY

Lasse Koskela. “Effective Unit Testing”

TEST PRACTICES

MAY THE TEST BE WITH YOU