Sep 23, 2022Liked by Kevin Rutherford

I like your focus on getting the names right. It's something that is usually overlooked, in particular between the tests labels and the code itself.

I would personally have kept the `const` in the tests instead of reaching out for parametrized tests. That's probably because I tolerate short-lived, non-reassignable, temp variables. I also like to see that kind of "Arrange-Act-Assert" structure. I feel the parametrized tests is more technical and harder to read from the source code—although the report is clear enough and it does DRY the code.

Now, at this point, either ways work. It's too early to tell which direction I would prefer in the end. So I like that you are taking these steps I wouldn't take for me… and I'm curious to see where we will land 😃

Expand full comment

Yes, I agree that the parameterised test is more technical and therefore harder for our Customer to read. But on the other hand I do like the symmetry of having a table of inputs and expected values, because so often it then becomes easy to spot gaps in our test list.

In the end, much of what I'm doing here is subjective. I'm hoping to expose as much of my thinking as possible, but still there's a huge reliance on personal taste.

Expand full comment

I also received this comment via email from Bill Wake (reproduced here with permission):

"Hi -

I'm enjoying your series.

I liked the move to parameterized tests, but felt like the arguments & message would read better in the other order. Sort of the difference between "Press 4 for the pharmacy department" vs. "For the pharmacy department, press 4" - a little less state to maintain.

I don't know if that's just a personal philosophy or if it resonates:)

Take care,


Expand full comment