Improving design and code quality with Property-based testing @ Q-con ABN AMRO 2019

Bf5494be4dd7a8e936cd964374d86eb0?s=47 João Rosa
September 11, 2019

Improving design and code quality with Property-based testing @ Q-con ABN AMRO 2019

A suite of traditional unit tests will only be as strong as the possible arguments or parameters tested against your code. Quoting Romeu Moura: If you take a String as an argument, then the works of Shakespeare in Japanese & Korean are ONE valid input. Obviously, this can be achieved with parameterized testing. However, this makes the unit tests so big that it is harder to understand which behaviour it is validating. We want our unit tests to also serve as living documentation so they should be comprehensible and to the point.

Enter Property-Based Testing. In Property-Based Testing, we randomly generate data points within the boundary of a property to verify the property’s behaviour. This not only lets us test edge cases that could expose unwanted and unexpected errors in the code but also enables us to make small tests that are readable and clear. Making these tests will also force you to think harder about the problem at hand and improve your design and code quality.

In this technical session, João demonstrates and explains what property-based testing is, and how to implement it in C# with FsCheck and Java with JUnit-Quickcheck. If you are interested in improving your unit testing, so you don’t have to worry much about test data anymore, but more about the problem your code is solving, this talk is for you!

Bf5494be4dd7a8e936cd964374d86eb0?s=128

João Rosa

September 11, 2019
Tweet

Transcript

  1. Improving design and code quality with Property-based testing

  2. 2 Strategic Technology Consultant Domain-Driven Design - Continuous Delivery -

    EventStorming @joaoasrosa joaorosa.io
  3. None
  4. None
  5. 5 @joaoasrosa

  6. None
  7. None
  8. 8 @joaoasrosa

  9. None
  10. 10 @joaoasrosa

  11. 11 The greatest obstacle to discovery is not ignorance -

    it is the illusion of knowledge. - Daniel J. Boorstin @joaoasrosa
  12. None
  13. 13 @joaoasrosa

  14. 14 @joaoasrosa

  15. 15 @joaoasrosa

  16. 16 Testing should be about: Learning from mistakes instead of

    only confirming @joaoasrosa
  17. 17 @joaoasrosa

  18. 18 @joaoasrosa

  19. blue yellow yellow red green purple blue blue green purple

    yellow red green yellow purple blue red yellow green red blue purple yellow purple red blue purple blue green yellow red red purple green yellow blue blue yellow green red purple yellow blue green red purple yellow red blue green purple green red yellow purple blue purple green red blue yellow yellow red green purple blue blue green purple yellow red green yellow purple blue red yellow green red blue purple yellow purple red blue green red purple yellow blue green red purple yellow red blue green purple green red yellow purple blue purple green red blue yellow yellow red green purple blue blue green purple yellow red green yellow purple blue red yellow green red blue purple yellow purple red blue green red purple yellow blue green red purple yellow red blue green purple green red yellow purple blue purple green red blue yellow yellow
  20. 20 @joaoasrosa

  21. 21 To communicate effectively, the code must be based on

    the same language used to write the requirements - the same language that the developers speak with each other and with domain experts - Eric Evans @joaoasrosa
  22. 22 Testing should be about: Living documentation on behaviour instead

    of on data @joaoasrosa
  23. None
  24. 24 Dave Farley - Continuous Delivery Feedback Quickly Timely Reliable

    Customer @joaoasrosa
  25. 25 Releasing software is too often an art; it should

    be an engineering discipline - Dave Farley @joaoasrosa
  26. 26 Testing should be about: Fast feedback on new demands

    instead of slow changes @joaoasrosa
  27. 27 Single abstraction examples (aka Unit tests) • Learning from

    mistakes instead of only confirming • Fast feedback on new demands instead of slow changes • Living documentation on behaviour instead of on data @joaoasrosa
  28. 28 In comes Property-based testing The construction of tests such

    that, when these tests are fuzzed, failures in the test reveal problems with the system under test @joaoasrosa
  29. 29 Fuzzing in Property-based testing Randomly generate data points within

    the boundary of a business invariant to verify the behaviour of the system @joaoasrosa
  30. 30 Frameworks: Haskell: Quickcheck Java Junit4: JUnit-Quickcheck Java JUnit5: jqwik

    C# & F#: FsCheck and Hedgehog @joaoasrosa
  31. None
  32. 32 @joaoasrosa

  33. None
  34. None
  35. 35 Human CI • Always run tests locally before commiting

    • Once the code is committed, wait for the result of commited build ◦ Don’t go home, to lunch, to a meeting, to make coffee • If a teammate has gone home, lunch…. revert their changes! • Fix or revert within 10 minutes • When there are failures, Pair or Mob and learn together Dave Farley - Continuous Delivery @joaoasrosa
  36. 36 Software Development is a learning process, working code is

    a side effect - Alberto Brandolini @joaoasrosa
  37. 37 Benefits • Covers (eventually) the scope of all data

    points, forget about data • Shrinker looks for a small use case • Reproducible tests Next thing -> Fuzzing invalid inputs in System Tests @joaoasrosa
  38. 38 Summary • (Also) Write tests with the intention of

    breaking code • Forget about data, focus on behaviour! • Quickly, Timely, Reliable Feedback • Human CI • Ohh… Have I mentioned Domain-Driven Design? @joaoasrosa
  39. 39 @joaoasrosa C# https://github.com/joaoasrosa/techorama-nl-property-based-testing Java https://gitlab.com/Baasie/Property-Based-Testing