{"id":2076,"date":"2019-12-11T17:05:35","date_gmt":"2019-12-11T16:05:35","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/uncategorized\/how-to-challenge-your-code-with-property-based-testing-part-1\/"},"modified":"2021-12-23T14:12:19","modified_gmt":"2021-12-23T13:12:19","slug":"how-to-challenge-your-code-with-property-based-testing-part-1","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/devops\/qa-testing\/how-to-challenge-your-code-with-property-based-testing-part-1\/","title":{"rendered":"How to Challenge Your Code with Property-Based Testing – Part 1"},"content":{"rendered":"

What does Property-Based Testing mean for developers? Well, a debate persists in software<\/span> as to the exact nature, division and scope of “testing” activities. We need to check that a particular software component produces the expected output with the expected inputs provided. Yet we also need to expose the behaviour of this component against unforeseen or unpredictable inputs.<\/p>\n

The first activity is usually referred to as “checking”, while the second is called “exploring” and both contribute to defining the software components as “tested”.<\/p>\n

The boundary that divides these two different activities is often linked to the level of knowledge<\/span> of the component being examined. However, we must be very careful not to confuse the knowledge<\/span> of the issue under analysis with the illusion of knowledge<\/span>.<\/p>\n

\"the<\/picture>
The illusion of knowledge<\/span><\/figcaption><\/figure>\n

Introducing the Black Swan Theory<\/h2>\n

A common example of the negative effects of the illusion of knowledge<\/span> is the so-called “black swan theory” introduced by Nassim Nicholas Taleb in 2007. In short, if it is assumed that all swans are white and that, therefore, black swans cannot exist, it means the existence of a single black swan can bring down the whole theory.<\/p>\n

In the field of testing, the illusion of knowledge<\/span> is linked to the cognitive bias<\/span><\/strong> that, want it or not, we apply both when we write code and when we design and structure the various tests and test cases necessary to confirm the functionality of the code itself.<\/p>\n

Some types of automatic tests, such as unit tests, only allow confirmation of the behaviour<\/strong>. An example is the confirmation of the occurrence of a certain condition. What could happen unexpectedly in code like the following?<\/p>\n

<script src=”https:\/\/gist.github.com\/elleuca\/267b5db40dd72c03234c5eb76b9835c5.js”><\/script><\/p>\n

It is preferable to add the various limit cases of interest. However,\u00a0 the illusion of knowing the range within the price we will pass to the function will vary. This could lead to the belief<\/span> that it will never provide a value that can produce an unexpected result.<\/p>\n

Have you ever tried to use Shakespeare’s entire work in Japanese and Korean as an input to your method that takes a valid string as a parameter? It’s an impossible case, so why should we use it as input for a test?<\/p>\n

Qualities of Good Testing<\/strong><\/h2>\n

What we could expect from good testing? At Codemotion Rome 2019<\/a>, Kenny Baas and Jo\u00e3o Rosa shared their ideas about how testing should work to shift from just confirming to learning<\/span>. When your software breaks, it is caused by at least one mistake. It happens, but you can leverage those mistakes to learn more about what you built<\/strong> or the actual context of the problem you are trying to solve.<\/p>\n

\"Single<\/picture>
Abstraction as Unit testing<\/figcaption><\/figure>\n

Learn and Challenge Code Through Property Based Testing<\/h2>\n

If you want to learn more about the context, or the domain you are working on, your tests should describe and communicate what is happening. Domain-Driven Design can help you to write code that is based on the same language developers speak with each other and other domain experts. Tests should help you to document how your software<\/span> behaves<\/strong>, not assert that it can pass a pile of anonymous data points.<\/p>\n

To challenge the code you wrote, you need to move away from the comfort zone of known valid inputs and feed it unforeseen data<\/span> that can disprove your illusion of safety. If you can do so, failures<\/span> in tests will reveal an actual problem in your system<\/strong>. If not, the tests will only assert that your system will work when it flows as expected.<\/p>\n

Such kind of testing is called \u201cproperty based testing\u201d and helps to introduce a degree of fuzziness in test inputs<\/strong>, allowing to move from single abstraction examples (a.k.a. unit tests) to an active scanning of system behaviour.<\/p>\n

In the next article of this series, we\u2019ll explore more about how to start building property based testing. Stay tuned…<\/p>\n

\n
\n