Property-based testing and HATEOAS

Weekly, I dedicate time to expanding my skills and knowledge as a software developer. I aim to document my learnings and share them with the community to foster growth and collaboration.

While property-based testing shares similarities with parametrized unit tests, its essence lies in exploring a domain and establishing properties rather than solely focusing on parameterization.

Consider this scenario: We aim to create a function for sorting a list of numbers. Traditionally, we might approach this by writing a unit test such as:

// Given
def list = [7, 5, 6]

// When
def result = sort(list)

// Then
assert result == [5, 6, 7]

Indeed, while parametrized testing allows us to test multiple cases, property-based testing differs in its approach. In property-based testing, we define properties inherent to our system. For instance, in the case of sorting a list of numbers, one property could be that each subsequent number in the sorted list is greater than or equal to the preceding number.

To illustrate this, consider the following property-based test:

// Given
def list = generateListOfNumbers()

// When
def result = sort(list)

// Then
assert result[0] <= result[1]
assert result[1] <= result[2]

In my pseudo-code, I mentioned a function called generateListOfNumbers, which highlights another crucial aspect of property-based testing. Property-based testing frameworks generate thousands of random lists, aiming to stress-test your code and uncover potential vulnerabilities.

While random values are typically discouraged in traditional unit tests, they play a pivotal role in property-based testing. By subjecting your code to a variety of randomly generated inputs, property-based testing assesses whether the defined property holds true across diverse scenarios.

Should a test fail during property-based testing, the testing framework automatically saves the problematic case. This enables you to isolate and rerun the specific case, facilitating the debugging process. Consequently, property-based testing should be viewed as an augmentation to traditional unit tests rather than a replacement.

This talk from 2019 is absolutely fantastic. It’s packed with valuable insights and information. You should definitely give it a watch!

REST beyond the Obvious - API Design for ever Evolving Systems • Oliver Drotbohm • GOTO 2019:

The speaker discussed strategies for mitigating coupling in the design of REST APIs, and one approach he highlighted was HATEOAS. It was eye-opening for me because I hadn’t previously considered HATEOAS as a solution. He provided a compelling example to illustrate its effectiveness.

My site is free of ads and trackers. Was this post helpful to you? Why not

Reference: