Improving design and code quality with Property-based testing @ Codemotion Rome 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, Kenny & 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!

Transcript

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

   View Slide

2. 2
   Strategic Technology Consultants -
   Agile Technical Coaches -
   Domain-Driven Design - Continuous
   Delivery - EventStorming - Example
   Mapping
   @kenny_baas
   baasie.com
   @joaoasrosa
   joaorosa.io
   

   View Slide

3. View Slide

4. View Slide

5. 5
   @kenny_baas @joaoasrosa
   @kenny_baas @joaoasrosa
   

   View Slide

6. View Slide

7. View Slide

8. 8
   @kenny_baas @joaoasrosa
   

   View Slide

9. View Slide

10. 10
    @kenny_baas @joaoasrosa
    

    View Slide

11. 11
    @kenny_baas @joaoasrosa
    The greatest obstacle to discovery is not ignorance -
    it is the illusion of knowledge.
    - Daniel J. Boorstin
    

    View Slide

12. View Slide

13. 13
    @kenny_baas @joaoasrosa
    

    View Slide

14. 14
    @kenny_baas @joaoasrosa
    

    View Slide

15. 15
    @kenny_baas @joaoasrosa
    

    View Slide

16. 16
    @kenny_baas @joaoasrosa
    Testing should be about:
    Learning from mistakes
    instead of only confirming
    

    View Slide

17. 17
    @kenny_baas @joaoasrosa
    

    View Slide

18. 18
    @kenny_baas @joaoasrosa
    

    View Slide

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
    

    View Slide

20. 20
    @kenny_baas @joaoasrosa
    

    View Slide

21. 21
    @kenny_baas @joaoasrosa
    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
    

    View Slide

22. 22
    @kenny_baas @joaoasrosa
    Testing should be about:
    Living documentation on
    behaviour instead of on data
    

    View Slide

23. View Slide

24. 24
    @kenny_baas @joaoasrosa
    Dave Farley - Continuous Delivery
    Feedback
    Quickly
    Timely
    Reliable
    Customer
    

    View Slide

25. 25
    @kenny_baas @joaoasrosa
    Releasing software is too often an art;
    it should be an engineering discipline
    - Dave Farley
    

    View Slide

26. 26
    @kenny_baas @joaoasrosa
    Testing should be about:
    Fast feedback on new demands
    instead of slow changes
    

    View Slide

27. 27
    @kenny_baas @joaoasrosa
    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
    

    View Slide

28. 28
    @kenny_baas @joaoasrosa
    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
    

    View Slide

29. 29
    @kenny_baas @joaoasrosa
    Fuzzing in Property-based testing
    Randomly generate data points
    within the boundary of a business invariant
    to verify the behaviour of the system
    

    View Slide

30. 30
    @kenny_baas @joaoasrosa
    Frameworks:
    Java Junit4: JUnit-Quickcheck
    Java JUnit5: jqwik
    C#: FsCheck
    

    View Slide

31. View Slide

32. 32
    @kenny_baas @joaoasrosa
    

    View Slide

33. View Slide

34. View Slide

35. 35
    @kenny_baas @joaoasrosa
    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
    

    View Slide

36. 36
    @kenny_baas @joaoasrosa
    Software Development is
    a learning process, working code is a
    side effect
    - Alberto Brandolini
    

    View Slide

37. 37
    @kenny_baas @joaoasrosa
    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
    

    View Slide

38. 38
    @kenny_baas @joaoasrosa
    Summary
    ● (Also) Write tests with the
    intention of breaking code
    ● Forget about data, focus on behaviour!
    ● Quickly, Timely, Reliable Feedback
    ● Human CI
    ● Ohh… Have we mentioned
    Domain-Driven Design?
    

    View Slide

39. 39
    @kenny_baas @joaoasrosa
    C#
    https://github.com/joaoasrosa/techorama-nl-property-based-testing
    Java
    https://gitlab.com/Baasie/Property-Based-Testing
    

    View Slide

40. #CatTax
    

    View Slide