{"id":3377,"date":"2020-02-14T11:28:40","date_gmt":"2020-02-14T10:28:40","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=3377"},"modified":"2021-12-23T14:10:07","modified_gmt":"2021-12-23T13:10:07","slug":"how-to-challenge-your-code-with-property-based-testing-part-3","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/devops\/qa-testing\/how-to-challenge-your-code-with-property-based-testing-part-3\/","title":{"rendered":"How to Challenge Your Code with Property-Based Testing \u2013 Part 3"},"content":{"rendered":"\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\tTable Of Contents\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
  1. Property-based testing: quick recap<\/a>
  2. Realistic Case Scenario – Generators<\/a>
  3. Debugging a Disproven Property<\/a><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n

    Property-based testing suggests a new way to test software, going beyond the example-based approach and stressing your code with random, realistic inputs. Follow this 3-issue mini serie about property-based testing and Kenny Baas and Jo\u00e3o Rosa speech at Codemotion Rome 2019.<\/p>\n\n\n\n

    Property-based testing: quick recap<\/h2>\n\n\n\n

    In this third and last issue about property-based testing (see the first issue here<\/a>, and the second one here<\/a>), we\u2019ll see how this approach — and some interesting features provided by QuickCheck, the reference library for property-based testing — can help us to set up meaningful and useful tests for our methods and functions. But before going any deeper, a quick summary about what we have learned about property-based testing so far.<\/p>\n\n\n\n

    Property-based tests are, in short, parameterized tests on steroids<\/strong>, that can feed test methods with a sequence of random inputs. Each test method must be designed to check and assert the desired behavior<\/strong> (property) from an input, usually within a given range. This approach gives to property-based testing the ability to \u201cexplore\u201d what could happen in previously unforeseen conditions. <\/p>\n\n\n\n

    So, if we are writing a test to check our super fast method to reverse an array of strings, we should not check that given [\u201ca\u201d, \u201cn\u201d, \u201ck\u201d]<\/code>, the result is [\u201ck\u201d, \u201cn\u201d, \u201ca\u201d]<\/code>, but we could check, for instance,  that reversing any random array of string we have a different array and reversing it again we have the same initial one. If or when the test fails, we have found a sequence that breaks our code.<\/p>\n\n\n\n

    This example introduces us to the main topics of this issue: how to generate a random input<\/strong> for a non-basic data\/object and how to reproduce a failing run\/scenario<\/strong>.<\/p>\n\n\n\n

    Realistic Case Scenario – Generators<\/h2>\n\n\n\n

    Let\u2019s do it building code and tests for a realistic scenario: redeeming fidelity points bonus when our customer buys 3 or more special product with a single purchase. How can we check it with property-based testing? How property-based testing can help us to improve our code? Let\u2019s see it.<\/p>\n\n\n\n

    We can, as a first move, write our checks using a \u201cplain\u201d unit based testing. We have two different cases to check: the first one is when our customer will do a purchase that can redeem fidelity points, the second one is when the purchase can\u2019t redeem points. Our tests can be something like the following:<\/p>\n\n\n\n