> test coverage which hints maybe the author didn't consider these cases In my reviews, when I look at the tests, I put on a test engineer hat. Testers like t

> test coverage which hints maybe the author didn't consider these cases In my reviews, when I look at the tests, I put on a test engineer hat. Testers like to do things like give an empty value where one is supposed to be required by the business logic, a negative or other out-of-range value, an emoji or other wonky unicode in text. Just basic stuff to a test engineer, but lots of programmers only write tests for the expected happy path, and maybe one or two cases for common alternate paths. The most common failures I find are in handling dates and date comparisons. I've been wanting to add more fuzz testing to the tests I write, but I haven't quite gotten my head around how to do it effectively.