Tell Me Why I Don't Like -Testing-
One of my earliest professional jobs was writing avionic test software for fighter jets, bombs, and missiles. It was exciting to work with such awesome machines. I enjoyed the mix of hardware and software. I once wrote a “soft” oscilloscope application that read signals from a PC board and displayed the signal forms. Not that that matters, but it was fun and I enjoyed it.
I mention this because there is a misconception that software engineers don’t like to test or write tests. They just don’t like doing meaningless or wasted work; it is like not liking Mondays. I am not saying that testing is meaningless or wasted. However, I will claim that many testing methodologies and policies are.
Some examples:
100% Code Coverage Mandates
It is frustrating to be forced to write tests for things that can never fail, just to get code or branch coverage. Writing boilerplate tests and “mocking out the world” makes code smell bad and lowers development satisfaction. Many teams choose to require that their tests have 100% code coverage (or some very high percentage). I’m surprised at how many posts and recommendations there are for this. A high percentage of code coverage isn’t bad, but requiring it is. Fortunately, there are prominent industry leaders who have spoken out about it. A high test coverage goal is probably the wrong goal to have. There are better goals and metrics.
All requirements should have tests. Quantify features and requirements and have a high percentage (or 100%) of sociable tests for the public interfaces for those use cases. This should yield a high percentage of code coverage. If not, then there might be dead code or undocumented features. Using test coverage to find areas that have missing tests is a better use of test coverage metrics. The frequency and severity of defects is a good indicator of the quality of a test suite. A defect is a sign of a missing test. When they happen, it’s not too late; tests can and should be written for defects.
I expect a high level of coverage. Sometimes managers require one. There’s a subtle difference.
- “code coverage” in this discussion includes “branch coverage”.
Testing That Hinders Refactoring
Testing methodologies that get in the way of refactoring, adding new features, or otherwise making changes and improving the software will create disdain for testing. It is best to avoid making refactoring harder or adding resistance to refactoring. In general, if a software change does not change functionality, changes to tests should also not be needed.
Solitary unit tests usually lead to this problem. A heavy use of mocks is an indication that unit tests are getting in the way of software development and causing engineers to hate testing. Mocks are useful, but avoid them. They prevent testing the interactions between objects. I won’t go as far as to say that “if you are using mock objects you are doing it wrong” but I do agree with the sentiment. And fakes are better.
if you mock too much you may wind up with test suites that are slow, fragile, and complicated; and you may also damage the design of your application
Coding in Cucumber
According to the Cucumber founder, Aslak Hellesøy, “Cucumber is not a testing tool”, nor is it “test automation". It should not be used as a testing framework. Cucumber is a Behavior-Driven Development (BDD) “collaboration” tool. The “Three Amigos” (business analysts/TPMs, programmers, and testers) are supposed to sit down and write Cukes before any code is written (this is related to Test Driven Development TDD, but is not the same). Ideally, non-technical people write Cukes in natural language. Cukes should not be fine grained and shouldn’t look like marked up curl and reference APIs. Doing so will also lead to frustrated engineers who begin to hate testing.
Clearing the Air
Admittedly there are engineers who like to just write code and struggle to bring themselves to write pesky tests. However, we don’t have to make it a bad experience and it is part of creating quality code. Usually, dealing with bugs after releases and production incidents are enough for engineers to have a healthy respect and desire for writing tests.
Some additional reading on the topic: