Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mutation Testing - Better code by making bugs

Théo FIDRY
September 22, 2017

Mutation Testing - Better code by making bugs

Théo FIDRY

September 22, 2017
Tweet

More Decks by Théo FIDRY

Other Decks in Programming

Transcript

  1. WHO DOES • UNIT TESTING • TEST-DRIVEN DEVELOPMENT • CONTINUOUS

    INTEGRATION • MEASURE CODE COVERAGE • MUTATION TESTING 4
  2. PROBLEMS • How do I safely refactor my tests? •

    How do I know I can trust a test suite? • How do I ensure my team is writing effective tests • How do I know if I’ve retrofitted enough tests to safely refactor a piece of legacy code? 5
  3. COMMON ANSWERS • Don’t worry, it’ll be fine • I’m

    a ninja rockstar, I know my tests are good • I do TDD, I know my tests are good • What about the tests you didn’t write? • How do you test drive changes to tests? • Code review • Inconsistent + Labour intensive • Code coverage 7
  4. 13

  5. 14

  6. 15

  7. EXAMPLES • A + B —> A - B •

    A && B —> A || B • Literal value replacement: 0 -> 1, true -> false… • Statement deletion: return, break, continue… • … 22
  8. CODE COVERAGE HIGHLIGHTS CODE THAT IS DEFINITELY NOT TESTED MUTANT

    SCORE HIGHLIGHT CODE THAT IS DEFINITELY TESTED 27
  9. 30

  10. 31

  11. 33

  12. 34

  13. 35

  14. WHY DOES IT WORK? “Complex faults are coupled to simple

    faults in such a way that a test data set that detects all simple faults in a program will detect most complex faults” Demonstrated in 1995 by K. Wah, “Fault coupling in finite bijective functions” 37
  15. IT IS NOT NEW… - HISTORY • Begins in 1971,

    R. Lipton, “Fault Diagnosis of Computer Programs” • Generally accepted in 1978, R. Lipton and al, “Hints on test data selection: Help for the practicing programmer” 38
  16. WHY IS IT NOT WIDELY USED? Maturity Problem: Because testing

    is not widely used yet (Although it is increasing) 39
  17. WHY IS IT NOT WIDELY USED? Integration Problem: Inability to

    successfully integrated it into software development process (TDD plays a key role now) 40
  18. OPTIMISATION STRATEGIES • 2,155 tests in 6.82 seconds 
 (0.00316s/tests)

    • 957 mutants • 2,062,335 tests • ~1h49min With Humbug 43
  19. 44

  20. OPTIMISATION STRATEGIES • Reduce equivalent mutant detection techniques (10 to

    40% of mutants are equivalent) • Take coverage to mutate only covered code • Rely on coverage to know which tests to run and which to run first • Increment analysis 45
  21. OPTIMISATION STRATEGIES • 2,155 tests in 6.82 seconds 
 (0.00316s/tests)

    • 957 mutants • 2,062,335 tests • 13min48 (vs. ~1h49min) With Humbug 46
  22. FUTURE WORK IN HUMBUG • Humbug vs. Infection • AST

    based mutations • Performance optimisations • Test framework support 47
  23. THE GOOD PARTS • Detect problems with your tests •

    They discover dead code • They are automatic • Test your tests with little effort 49
  24. THE NOT SO GOOD PARTS • Mutation testing is slow

    • Handful of libraries • Equivalent mutant problem • Writing complex mutant tests is difficult 50