Search⌘ K
AI Features

Testing Specials

Explore how to develop property-based tests for special pricing scenarios in Erlang using PropEr. Understand how to build complex custom generators that combine regular and special item lists to produce reliable expected prices. Learn to design tests that isolate special pricing logic for better bug detection and consistent results.

Getting started

Rather than modifying the existing property, which does a fine job of checking non-special prices, we’ll add a new one to check specials. The separation will help narrow down problems when they happen. If the property for basic prices always works, then we’ll know that failures in the separate special property likely relate to bugs in the special one’s handling.

Let’s take a look at the property that we could implement.

prop_special() ->
    ?FORALL({ItemList, ExpectedPrice, PriceList, SpecialList},
            item_price_special(),
        ExpectedPrice =:= checkout:total(ItemList, PriceList, SpecialList)).

This property is similar to the one we wrote earlier, except that we now expect another term out of the generator, which is a list of special prices, SpecialList in Erlang. The easiest way to go about this would be to just come up with a static list of specials and then couple it with the previous property’s generator, but that wouldn’t necessarily exercise the code as well as fully dynamic lists, so let’s try to do that instead.

Planning the generators

First things first, we’ll need the basic list of items and prices. For that, we can reuse the price_list() generator, which gives us a fully dynamic list. Then, if we want the specials list to be effective, we should probably build it off the items in the price list. That can be done by ...