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
87
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
310
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
870
The Scientific Programmer - Eric Bouwers
joyofcoding
0
200
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
SOCI Index Manifest v2が出たので調べてみた / Introduction to SOCI Index Manifest v2
tkikuc
1
110
OSS開発者という働き方
andpad
5
1.5k
旅行プランAIエージェント開発の裏側
ippo012
1
520
CSC305 Summer Lecture 12
javiergs
PRO
0
130
KessokuでDIでもgoroutineを活用する / Go Connect #6
mazrean
0
120
The State of Fluid (2025)
s2b
0
210
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
180
開発チーム・開発組織の設計改善スキルの向上
masuda220
PRO
17
9.4k
Google I/O recap web編 大分Web祭り2025
kponda
0
2.9k
Portapad紹介プレゼンテーション
gotoumakakeru
1
130
レガシープロジェクトで最大限AIの恩恵を受けられるようClaude Codeを利用する
tk1351
4
1.5k
Improving my own Ruby thereafter
sisshiki1969
1
130
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
A designer walks into a library…
pauljervisheath
207
24k
Site-Speed That Sticks
csswizardry
10
800
Six Lessons from altMBA
skipperchong
28
4k
The Language of Interfaces
destraynor
160
25k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Navigating Team Friction
lara
189
15k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Cult of Friendly URLs
andyhume
79
6.6k
How GitHub (no longer) Works
holman
315
140k
Automating Front-end Workflow
addyosmani
1370
200k
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?