Let’s wrap up this series of tips, and show one final example when setting an explicit primary key value can improve the quality of your tests.
This is part 3 of 3, so if you missed the previous posts, I’d recommend reading part 1 and part 2 first. You’re not one of those people that watches movies or reads books out of order, are you?
Sorting and filtering logic
When presenting a list of records, it’s very common to apply either a default or user-selected sort. Is this worth testing? I say yes.
If we’re not careful, we might assert things are sorted by date, but if we create the records in a default order, it’s possible it could pass for a reason other than what we’re expecting.
I use a mix of techniques, including specifying the primary key, to increase my confidence that I’m actually testing the logic I intend to test. Take a look at this test setup:
<?php factory(Season::class)->create([ 'id' => 44, 'name' => 'chicken', 'start_date' => '2019-01-01', 'end_date' => '2019-03-31', ]); factory(Season::class)->create([ 'id' => 45, 'name' => 'steak', 'start_date' => '2018-01-01', 'end_date' => '2018-03-31', ]); factory(Season::class)->create([ 'id' => 46, 'name' => 'buffalo', 'start_date' => '2018-04-01', 'end_date' => '2018-12-31', ]);
I want to make sure my seasons are sorted in reverse chronological order, based on start date. The above setup was carefully chosen to increase confidence. I specifically create the items with names and dates sorted differently than the primary key.
<?php $orderedResult = [ [ 'id' => 44, 'name' => 'chicken', ], [ 'id' => 46, 'name' => 'buffalo', ], [ 'id' => 45, 'name' => 'steak', ], ];
My response doesn’t include the dates. I only get
name. But because of how I set up my test, I can make an assertion based purely on those values and be confident it was my logic ordering the results, not some unintended side-effect putting them in the desired order for some other reason.
This example doesn’t test any filtering, but the same principles apply.