GlyphI've seen a lot of people talking about the practice of code review in a way that I consider unrealistic lately. So here are my thoughts on what code review is—and isn't—for: https://blog.glyph.im/2026/03/what-is-code-review-for.html
Per Vognsen@glyph My only question is with your comment on deterministic testing. I would think randomized property testing and other forms of fuzzing are especially suitable in this case because it's harder to "code to the test" in the way you can for a deterministic test suite. And that's aside from the general advantages of property testing. (I nodded vigorously to everything you said about code review.)
John-Mark Gurney@pervognsen
Why not both?
Deterministic for the single variable testing, e.g. make sure specific code paths are executed and covered.
Then you can use fuzzing as a type of pair wise testing, that is, making sure to cover combinations of paths that might not be expected through normal deterministic testing.
@encthenet @pervognsen sorry yes, fuzzing is a fine way to find bugs. while it is stochastic, it has a much more bounded error range on its behaviors. but it’s also less universally applicable than regression testing, and this was a very broad post. not all software has interesting broad ranges of inputs where surprises can happen, some has a quite constrained and simple set of business process rules that it follows