What Is a Useful Property Test for Time Sorting?
From the earlier reference collection. Read the current software blog.
Generate service times around midnight and assert ordering by their service-day values rather than clock-face strings.
Choose the value that defines order
A schedule time may belong to a service day that continues past midnight. In that representation, 25:10:00 means one hour and ten minutes after the next calendar midnight, but it still sorts after 23:50:00 on the same service day. Sorting by the printed hour or by a converted wall-clock time can place it incorrectly.
A useful property test generates valid service-time values and checks that sorting by the application’s ordering key produces a nondecreasing sequence. The key should reflect the service-day offset or elapsed seconds from the service-day start, according to the data model.
Generate cases around the boundary
Bias generated values toward the tricky region: just before midnight, exactly at midnight, and shortly after midnight represented as an hour above 24. For example, create 23:58:00, 24:03:00, and 25:10:00, then shuffle them. The sorted result should preserve that chronological order for the service day.
Include several values within the same hour and duplicate times. Duplicates should remain adjacent; if stable ordering matters, verify that records with equal times retain the documented tie-break order. Avoid generating malformed times unless the test is specifically about validation, since invalid-input behavior is a separate property.
Assert a relation, not one fixture
A property test can assert that for every neighboring pair in the sorted result, the first service-day value is less than or equal to the second. It can also assert that sorting an already sorted list leaves it unchanged. These checks cover many input permutations without hard-coding a single output list.
Keep a small named example beside the generated property. If the property fails, the explicit midnight case quickly communicates the intended behavior, while the generator can shrink a more complicated failure into a minimal counterexample. Compare numeric service-day values, not formatted strings, unless the format itself is what the application contract defines as sortable.
Make assumptions explicit
State whether the test operates on times alone or on complete trips with stop sequence information. Two trips can share a departure time, and an application may use route, trip, or sequence identifiers to make display order deterministic. Do not let an accidental ordering from a data structure become an undocumented promise.
This test is especially useful when schedule data crosses midnight or a refactor changes parsing and sorting code. Its central guarantee is simple: presentation order follows elapsed service-day time, even when the printed clock value exceeds 24 hours.