3 ms·
Don't write tests for things that can be more effectively tested in other ways, and lean on other correctness methodologies as much as possible. These include:
by cube00 4y ago
Don't write tests for things that can be more effectively tested in other ways, and lean on other correctness methodologies as much as possible. These include: code review
I'll take tests any day over the luck of getting an individual to pick up flaws in the code review.
- drewcoo 4y agoNo kidding. It should read: "Don't code review for things that can be more effectively tested in other ways, and lean on other correctness methodologies as much as possible."
- kortex 4y agoThey are complementary. I've had code reviews pick up gaps in unit tests (e.g. the code is covered, but the state space isn't), and I've had code reviews miss some absolute doozies. Also code review is as much about sharing knowledge and reducing bus factor (if not more so) than acting like some great filter.
- eyelidlessness 4y agoI agree, and I work on a team with impressively thorough review habits. The obvious reason is that tests allow reviewers to focus on more substantive questions than what the code behavior is (eg “is this the desired behavior?”). A less obvious reason, but more compelling to me, is that code which hasn’t changed is very unlikely to be reviewed in the context of changes under review, even if the unchanged code should have changed.