Most of us start our testing journey the same way: we think of a few scenarios, write them down as assertions, and call it a day. It’s what I call "Example-Based Testing." You provide a specific input, you define the specific output, and if they match, you feel a sense of security. The problem is that your tests are only as good as your imagination. If you didn't imagine that a user might pass an empty list, or a list with ten thousand identical integers, or a list containing only Int.MIN_VALUE, your tests won't find the bug.

The comfort of the known example

Imagine we're writing a custom sorting function for a specific business requirement. In a naive approach, your test suite probably looks like this:

fun testSort() {
    assertEquals(listOf(1, 2, 3), mySort(listOf(3, 1, 2)))
    assertEquals(listOf(10, 20, 30), mySort(listOf(30, 10, 20)))
    assertEquals(emptyList<Int>(), mySort(emptyList()))
}

This feels productive. You've covered the basic case, a different set of numbers, and the empty case. You commit the code, it passes the CI pipeline, and you go to lunch. But here is the trade-off: you aren't actually testing the logic of sorting; you're testing your ability to predict the output of a few specific cases. You've created a "happy path" bubble. If your mySort implementation has a subtle bug that only triggers when there are duplicate elements or when the list is already sorted in reverse, these tests will never find it because you didn't think to write a test for those exact inputs.

Where the edges hide

The danger of example-based testing is that it rewards confirmation bias. We write tests for the cases we know the code handles. Property-Based Testing (PBT) flips this on its head. Instead of picking the inputs, you define the properties that must always be true, regardless of the input.

If you're sorting a list, what is actually true about the result? First, the sorted list must have the same number of elements as the original. Second, for every element at index i, it must be less than or equal to the element at i + 1. Third, the sorted list must contain the exact same elements as the original (it's a permutation).

By defining these invariants, you stop guessing. You tell the testing framework: "Generate a hundred random lists of integers—some huge, some empty, some with duplicates—and tell me if any of them break these rules."

Defining the invariants

In Kotlin, using a library like Kotest, the shift in mindset looks like this. We stop writing assertEquals and start using forAll:

// This is the conceptual shift: from "example" to "property"
forAll(Arb.list(Arb.int())) { list ->
    val sorted = mySort(list)
    
    val sameSize = sorted.size == list.size
    val isOrdered = sorted.zipWithNext().all { (a, b) -> a <= b }
    val sameElements = sorted.groupBy { it } == list.groupBy { it }
    
    sameSize && isOrdered && sameElements
}

I love this approach because it forces you to actually understand the mathematical contract of your function. It's harder to write initially—thinking of properties is a different mental muscle than thinking of examples—but the payoff is immense. I've had PBT find edge cases in production logic that would have taken a human weeks of "guessing" to find via manual test cases.

The magic of shrinking

One legitimate complaint people have with random testing is that when it fails, it fails with a monstrous input. Imagine the framework generates a list of 500 random integers and finds a bug. Looking at a list of 500 numbers to find the one that caused the crash is a nightmare.

This is where "shrinking" comes in, and it's the secret sauce of PBT. When a property fails, the framework doesn't just throw the failure at you. It attempts to find the smallest possible input that still triggers the failure. It will try removing elements, simplifying numbers, or shortening the list until it can say: "I found a failure with 500 elements, but actually, the simplest version of this bug happens with just this specific list: [0, 0]."

This turns a needle-in-a-haystack debugging session into a clear, actionable report. You get the coverage of a million random tests with the precision of a hand-written unit test.

📋 Practical Task

Hardening a Pagination Logic with Property-Based Tests

You have a function calculatePageRange(totalItems: Int, pageSize: Int, currentPage: Int): IntRange that determines the start and end indices for a database query. The current implementation is prone to IndexOutOfBoundsException when the total items are fewer than the page size, or when the page requested is beyond the total count.

Your Task:

1. Implement the calculatePageRange function so it handles edge cases (e.g., totalItems = 0, currentPage = 1, or pageSize = 100).
2. Write a property-based test (conceptual or using a framework) that verifies the following properties for any combination of positive integers for totalItems, pageSize, and currentPage:
   • The start index of the range must never be negative.
   • The end index of the range must never exceed the totalItems.
   • The size of the resulting range must never be greater than the pageSize.

Ensure your solution doesn't just pass for "normal" numbers, but remains stable when the inputs are extreme.