Back to Feed
article 3m read

A test of mine cheered for the wrong product, and then a second wrong one turned up

Two name matchers in my ordering system let a product claim a different one whose name started the same way, and both of their tests asserted it as correct. Now names have to be equal, and the tests put the lookalike right next to the real thing.

Article DepthPractice

Flow

What happens to one report row now

  1. 1Clean the name

    Drop capitals, punctuation and the brand tag. Keep every word.

  2. 2Look for an equal name

    Compare against the names written down for each item on my list.

  3. 3One match

    Keep the row and line it up with my row for that item.

  4. 4No match

    Set it aside as old stock, like the hard candy in the new test.

  5. 5Two matches

    Stop with an error instead of guessing.

One test I wrote cheered for a bug, and I fixed it about twenty minutes later. Then I found the same bug in a second spot that same morning.

Checking suggestions against an outside report

The ordering system suggests what each store should reorder. I check those suggestions against a report from an outside tool. Before I compare, I throw out rows for products that aren't on my reviewed buying list. Those are old stock that the stores are just selling down.

To do that, the system has to decide which item on my list a report row is about. It does it by name. The report's names don't look exactly like mine, so the match has to forgive a bit.

That morning I also made both sides of the check line up on the list item they matched. That meant a wrong match no longer just let a row in. It also paired that row with the wrong one of mine.

Lemon Drop inside Lemon Drop Hard Candy

The old rule gave points for an exact name, and fewer points if my item's short name showed up inside the report's name. The best score won.

My test used one list item, which I'll call "Lemon Drop" in a "Sour Chews 10-pack", and one report row called "Lemon Drop Hard Candy". "Lemon Drop" is inside "Lemon Drop Hard Candy", so it scored, and the hard candy got treated as the sour chews. The test expected that and passed.

The trouble is that a test with one candidate can't catch this. A strict rule and a loose rule both say yes when there's nothing else to choose from.

Equal or nothing

Now a report row only matches if its cleaned-up name is equal to a name I've written down for that item. Cleanup ignores capitals, punctuation and the brand tag on the end, but keeps every word. If two list items both match one row, the code stops with an error instead of guessing.

match = [item for item in my_list if clean(name) in item.exact_names()]

The test now has both report rows. It expects the sour chews kept and the hard candy set aside as old stock.

Ginger Melt and Ginger Melt Mini

A different matcher links new order lines to older sales history, so that history can count as demand. It said two names were the same if one was inside the other. "Ginger Melt" could grab "Ginger Melt Mini".

Its test had only the lookalike, and it called that link correct. Now names must be equal, or the product codes must match, and the test has both names side by side.

Renamed products come back unmatched

More things now come back unmatched. On the report side I can write down an alias to fix that. On the history side there's no alias, so a renamed product just shows up as unmatched.

I haven't counted what lands on that history-side unmatched list yet.

Keep reading

Pick up a connected idea or branch into a nearby one.

5 paths forward