4 ms·
Maybe not perfectly framed, but the point that engineers don't have time to write tests is salient. Minor disagreement with this point though: > Tests can only
by r0s 3y ago
Maybe not perfectly framed, but the point that engineers don't have time to write tests is salient. Minor disagreement with this point though:
> Tests can only tell developers they made a mistake. There is no gain at that moment.
The value is locating the problem code faster, and that generally can't be done efficiently in production. Outside a testing environment, you rely on logs alone to debug, or if you're more proactive you might grab session data but that means potentially sensitive user data is being cached and passed around to the support/triage team. At a security minded organization this should be impossible or at least difficult.
I agree it's not worth chasing Test Driven Development until you're actually testing during development.
This is a real problem, and it falls squarely on management. Testing needs time and resources, it needs priority and planning.
That's the reason I started speaking at conferences, started an online testing training course specifically for software managers, and am currently writing a book on the subject.
- thakoppno 3y ago> potentially sensitive user data is being cached and passed around to the support/triage team An excellent point for most cases that ultimately cannot be satisfied for others. For instance, this most recent HTTP/2 Rapid Reset vulnerability, could it be solved without shared PCAPs?
- dickersnoodle 3y ago>> Tests can only tell developers they made a mistake. There is no gain at that moment. This is the dumbest thing I have seen on HN in a long, long time. Full test coverage supported by good mocks is one of the quickest and most efficient ways to find regressions that I know. Don't discount the value in helping developers see when they've made mistakes, especially when you're rotating junior and mid-level developers on and off your team.
- l72 3y agoWhen we have business logic changes or a bug fix, I require our developers to write test cases for the new behavior and commit that. I want to see those test fail in the CI systems. THEN they can implement the changes until the tests pass. When reviewing, the first thing I do is look at the tests. That is how I make sure developers understood the new requirements. Only after verifying that, so I then do a code review to critique implementation.