I’m like a test unitarian. Unit tests? Great. Integration tests? Awesome. End to end tests? If you’re into that kind of thing, go for it. Coverage of lines of code doesn’t matter. Coverage of critical business functions does. I think TDD can be a cult, but writing software that way for a little bit is a good training exercise.
I’m a senior engineer at a small startup. We need to move fast, ship new stuff fast, and get things moving. We’ve got CICD running mocked unit tests, integration tests, and end to end tests, with patterns and tooling for each.
I have support from the CTO in getting more testing in, and I’m able to use testing to cover bugs and regressions, and there’s solid testing on a few critical user path features. However, I get resistance from the team on getting enough testing to prevent regressions going forward.
The resistance is usually along lines like:
- You shouldn’t have to refactor to test something
- We shouldn’t use mocks, only integration testing works.
- Repeat for test types N and M
- We can’t test yet, we’re going to make changes soon.
How can I convince the team that the tools available to them will help, and will improve their productivity and cut down time having to firefight?
Well, optimally you really shouldn’t have to refactor to test something. If you need that, it means you can’t freely design your code for its function, and that the tests will break if you refactor again. You may be pushing tests that make your developers lives worse instead of better.
That said, yeah, some times one has to let go of the cleaner options and go punch the problem up until it’s solved. That happens often with tests. if that’s the case, you will need to do it through coercion. There are many tools that verify that tests are written, by more metrics than code coverage (but not any insightful metric). I’d pick a minimum of those and place them as a requirement.