Have you written a book, a dissertation, or a report? If you prepare well, everything should be almost perfect until you need to submit it to the editor, the professor, or the supervisor. In fact, almost likely you will read the manuscript again and again, just to ensure that there is no silly mistake, from typos to missing figures, which can be spotted easily in the draft. Before the document is going through another stage of proof-reading, you want to know as early as possible if something needs some fixes.
Fortunately, the same “multiple layers of defense” strategy applies to modern software development. For example, even though the compiler will scream at you if your code does not make sense, there is no reason to skip fixing it, if you happen to see it on your editor. Many complex application requires a rigorous testing procedure, yet it does not harm anyone to run the application through a fast smoke testing first. In fact, by the use of git pre-commit hook, you can run the smoke test before the defective code gets landed in the repository.
The principles are summarized as:
- If you screw up, you want to know earlier than later
- The first layer should have the lowest cost and effort
For client-side web development, this approach can be a time-saving. When you are in the coding stage, ideally the editor or the IDE which you use would give an instant feedback whenever there is something suspicious. It does not need to catch all possible cases, it has to be just good enough to filter the most common mistakes. If you leak a variable and it pollutes the global, there is no need to launch the unit tests before it gets caught.
Using CoffeeScript/Dart/TypeScript? Verify the compiled JavaScript with a syntax validator (because those code generators sometime have bugs, too). If you don’t use strict mode properly, there is no reason to wait for the full-blown QA workflow which involve a dozen web browsers (possibly even cloud-based) to kick in and then tell you that something is wrong. If your template handling does not produce the right DOM element, there is no use of running the functional tests on a whole set of mobile devices.
Just like a bodyguard, your layers of protection can be very subjective. Newbies may want more aggressiveness so that they can reduce the mistake probability. A typical configuration of those layers may look like the following:
- Editor/IDE with real-time code inspection
- Syntax validator
- Git pre-commit hook
- Quick headless testing
- Metrics guard, e.g. for code coverage
- Selenium-based comprehensive testing
This also demonstrates that an overlapping functionality does not always mean a substitution. Many tools complement each other quite well. Just because you have 100% code coverage does not mean you can’t benefit from a blazing-fast syntax error checking. Even if you aim to support legacy browsers, it does not mean you exclude yourself from doing headless testing.
Everyone makes mistakes. Fix them quickly and move on.