Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Kill the mutants, test your tests
Search
Joy of Coding
May 29, 2015
Programming
0
89
Kill the mutants, test your tests
Joy of Coding
May 29, 2015
Tweet
Share
More Decks by Joy of Coding
See All by Joy of Coding
Cool Code - Kevlin Henney
joyofcoding
0
320
Chris Granger - PROGRAMMING AS DISTRIBUTED COGNITION: DEFINING A SUPER POWER
joyofcoding
0
220
Cristina Lopes - Exercises in Programming Style
joyofcoding
0
490
Laurent Bossavit - The Joy of Debugging Ourselves
joyofcoding
0
240
Let Me Graph That For You: An Introduction to Neo4j - Ian Robinson
joyofcoding
1
160
Who’s afraid of Object Algebras? - Tijs van der Storm
joyofcoding
0
880
The Scientific Programmer - Eric Bouwers
joyofcoding
0
210
Building a web app in an hour - Trisha Gee
joyofcoding
0
260
Accelerating Agile - Dan North
joyofcoding
0
190
Other Decks in Programming
See All in Programming
プロダクト開発をAI 1stに変革する〜SaaS is dead時代で生き残るために〜 / AI 1st Product Development
kobakei
0
490
AIエージェント時代における TypeScriptスキーマ駆動開発の新たな役割
bicstone
4
1.5k
Breaking Up with Big ViewModels — Without Breaking Your Architecture (droidcon Berlin 2025)
steliosf
PRO
1
330
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
1.8k
GraphQL×Railsアプリのデータベース負荷分散 - 月間3,000万人利用サービスを無停止で
koxya
1
1.1k
クラシルを支える技術と組織
rakutek
0
190
Le côté obscur des IA génératives
pascallemerrer
0
120
CSC305 Lecture 04
javiergs
PRO
0
250
CSC509 Lecture 03
javiergs
PRO
0
330
CSC509 Lecture 05
javiergs
PRO
0
290
iOS 17で追加されたSubscriptionStoreView を利用して5分でサブスク実装チャレンジ
natmark
0
580
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
910
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Practical Orchestrator
shlominoach
190
11k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Building an army of robots
kneath
306
46k
Site-Speed That Sticks
csswizardry
11
880
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Transcript
KILL THE MUTANTS a better way to test your tests
ABOUT ME • Roy van Rijn • Mutants: • Nora
• Lucas • Works for
SHOW OF HANDS let's do a
WHO DOES • Unit testing • Test-driven development (TDD) •
Continuous integration • Measure code coverage • Mutation testing
UNIT TESTING • Prove your code works • Instant regression
tests • Improve code design • Has become a mainstream practise over the last 10 years
CONTINUOUS INTEGRATION • Automate testing • Maintain a single source
repository • Collect statistics
CODE COVERAGE • Measure the lines (or branches) that are
executed during testing
CODE COVERAGE • How did they test your car?
CODE COVERAGE • Who has seen (or written?) tests •
without verifications or assertions? • just to fake and boost coverage? • 100% branch coverage proves nothing
QUIS CUSTODIET IPSOS CUSTODES? Who watches the watchmen?
MUTATION TESTING • Proposed by Richard J. Lipton in 1971
(winner of 2014 Knuth Prize) • A better way to measure the quality of your tests • Surge of interest in the 1980s • Time to revive this interest!
TERMINOLOGY: MUTATION • A mutation is a (small) change in
your codebase, for example:
TERMINOLOGY: MUTANT • A mutant is a mutated version of
your class
MUTATION TESTING • Generate (a lot of) mutants of your
codebase • Run (some of) your unit tests • Check the outcome!
OUTCOME #1: KILLED • A mutant is killed if a
test fails (detecting the mutated code) • This proves the mutated code is properly tested
OUTCOME #2: LIVED • A mutant didn’t trigger a failing
test…
OUTCOME #3: TIMED OUT • The mutant caused the program
loop, get stuck
OTHER OUTCOMES • NON-VIABLE • JVM could not load the
mutant bytecode • MEMORY ERROR • JVM ran out of memory during test • RUN ERROR • An error but none of the above.
FAULT INJECTION? • With fault injection you test code •
Inject faults/mutations and see how the system reacts • With mutation testing you test your tests • Inject faults/mutations and see how the tests react
TOOLING • µJava: http://cs.gmu.edu/~offutt/mujava/ (inactive) • Jester: http://jester.sourceforge.net/ (inactive) •
Jumble: http://jumble.sourceforge.net/ (inactive) • javaLanche: http://www.st.cs.uni-saarland.de/mutation/ (inactive) • PIT: http://pitest.org/
USING PIT • PIT uses configurable ‘mutators' • ASM (bytecode
manipulation) is used to mutate your code • No mutated code is stored, it can't interfere with your code • Generates reports with test results
MUTATORS: CONDITION BOUNDARY > into >= < into <= >=
into > <= into <
MUTATORS: NEGATE CONDITIONALS == into != != into == <=
into > >= into < < into >= > into <=
MUTATORS: REMOVE CONDITIONALS into if(true) { //something } if(a ==
b) { //something }
MUTATORS: MATH + into - - into + * into
/ / into * % into * & into | << into >> >> into << >>> into <<< a++ into a-- a-- into a++
MUTATORS: MANY MORE • Replacing return values (return a; becomes
return 0;) • Removal of void invocations (doSomething(); is removed) • Some enabled by default, others are optional/configurable
MUTATION TESTING IS SLOW? • Speed was unacceptable in the
80's • Mutation testing is still CPU intensive • But PIT has a lot of methods to speed it up!
WHICH TESTS TO RUN? • PIT uses code coverage to
decide which tests to run: • A mutation is on a line covered by 3 tests? Only run those.
SIMPLE EXAMPLE • 100 classes • 10 unit tests per
class • 2 ms per unit test • Total time (all tests): 100 x 10 x 2ms = 2s
SIMPLE EXAMPLE • Total time (all tests): 100 x 10
x 2ms = 2s • 8 mutants per class, 100 classes x 8 = 800 mutants • Brute force: 800 x 2s = 26m40s • Smart testing: 800 x 10 x 2ms = 16s
LONGER EXAMPLE • Total time (all tests): 1000 x 10
x 2ms = 20s • 8 mutants per class, 1000 classes x 8 = 8000 mutants • Brute force: 8000 x 20s = 1d20h26m40s…!!! • Smart testing: 8000 x 10 x 2ms = 2m40s
PERFORMANCE TIPS • Write fast tests • Good separation or
concerns • Use small classes, keep amount of unit tests per class low
INCREMENTAL ANALYSIS • Experimental feature • Incremental analysis keeps track
of: • Changes in the codebase • Previous results
HOW ABOUT MOCKING? • PIT has support for: • Mockito,
EasyMock, JMock, PowerMock and JMockit
HOW TO USE PIT? • Standalone Java process • Build:
Ant task, Maven plugin • CI: Sonarqube plugin, Gradle plugin • IDE: Eclipse plugin (Pitclipse), IntelliJ Plugin
STANDALONE JAVA java -cp <your classpath including pit jar and
dependencies> org.pitest.mutationtest.commandline.MutationCoverageReport --reportDir /somePath/ --targetClasses com.your.package.tobemutated* --targetTests com.your.package.* --sourceDirs /sourcePath/
MAVEN PLUGIN Run as: mvn clean package org.pitest:pitest-maven:mutationCoverage <plugin> <groupId>org.pitest</groupId>
<artifactId>pitest-maven</artifactId> <version>1.0.0</version> <configuration> <targetClasses> <param>com.your.package.tobemutated*</param> </targetClasses> <jvmArgs>…</jvmArgs> </configuration> </plugin>
EXAMPLE Let’s kill some mutants… or be killed.
USE CASE The price of an item is 17 euro
If you buy 20 or more, all items cost 15 euro If you have a coupon, all items cost 15 euro
CODE public int getPrice(int amountOfThings, boolean coupon) { if (amountOfThings
>= 20 || coupon) { return amountOfThings * 15; } return amountOfThings * 17; }
TEST #1 @Test public void testNormalPricing() { //Not enough for
discount: int amount = 1; Assert.assertEquals(17, businessLogic.getPrice(amount, false)); }
BRANCH COVERAGE public int getPrice(int amountOfThings, boolean coupon) { if
(amountOfThings >= 20 || coupon) { return amountOfThings * 15; } return amountOfThings * 17; }
TEST #2 @Test public void testDiscountPricingByAmount() { //Enough for discount:
int amount = 100; Assert.assertEquals(1500, businessLogic.getPrice(amount, false)); }
BRANCH COVERAGE public int getPrice(int amountOfThings, boolean coupon) { if
(amountOfThings >= 20 || coupon) { return amountOfThings * 15; } return amountOfThings * 17; }
TEST #3 @Test public void testDiscountWithCoupon() { //Not enough for
discount, but coupon: int amount = 1; Assert.assertEquals(15, businessLogic.getPrice(amount, true)); }
BRANCH COVERAGE public int getPrice(int amountOfThings, boolean coupon) { if
(amountOfThings >= 20 || coupon) { return amountOfThings * 15; } return amountOfThings * 17; }
PIT RESULT
PIT RESULT > org.pitest.mutationtest…ConditionalsBoundaryMutator >> Generated 1 Killed 0 (0%)
> KILLED 0 SURVIVED 1 TIMED_OUT 0 NON_VIABLE 0 > MEMORY_ERROR 0 NOT_STARTED 0 STARTED 0 RUN_ERROR 0 > NO_COVERAGE 0 PIT tells us: Changing >= into > doesn’t trigger a failing test
TEST #4 @Test public void testDiscountAmountCornerCase() { //Just enough for
discount, mutation into > should fail this test int amount = 20; Assert.assertEquals(300, businessLogic.getPrice(amount, true)); }
BRANCH COVERAGE public int getPrice(int amountOfThings, boolean coupon) { if
(amountOfThings >= 20 || coupon) { return amountOfThings * 15; } return amountOfThings * 17; }
PIT RESULT
PIT RESULT > org.pitest.mutationtest…ConditionalsBoundaryMutator >> Generated 1 Killed 0 (0%)
> KILLED 0 SURVIVED 1 TIMED_OUT 0 NON_VIABLE 0 > MEMORY_ERROR 0 NOT_STARTED 0 STARTED 0 RUN_ERROR 0 > NO_COVERAGE 0 STILL WRONG!?
DID YOU SPOT THE BUG? @Test public void testDiscountAmountCornerCase() {
//Just enough for discount, mutation into > should fail this test int amount = 20; Assert.assertEquals(300, businessLogic.getPrice(amount, true)); }
SUMMARY • Mutation testing automatically tests your tests • Mutation
testing can find bugs in your tests • Code coverage is wrong, gives a false sense of security • Mutation testing with PIT is easy to implement
QUESTIONS?