Yesterday, I attended Unit Testing for Grown ups, a webinar with Gil Zilberfeld. Despite the title, it wasn't a tech-heavy tour through testing strategies, test doubles, or testability but instead a series of business arguments in favour of testing, primarily at the unit level.
If I had to sum it up in a couple of bullets, it'd be something like this:
- developers, your work does not start at the first line of production code and end when you push
- managers, your teams can probably work smarter
And if I had a few sentences, it'd go like this:
The goal of a software development group is to solve problems by writing code that "works" and is maintainable.
It is usually the case that as a codebase expands unintended side-effects occur more frequently and the costs of integration, testing, and bug fixing grow.
How to reduce these costs? Test first, and mostly at the unit level.
But the tests have to be good tests so developers should train their creative skills for thinking about possible problems, and then provide coverage for the right set of them.
This will be easier if the code is testable. Which means that testability needs to be part of the design of the system.
Test-Driven Development could be a great way to address all of the points above but it can be hard to get your head around the cost-benefit payoff (as a developer and manager), hard to begin, and then also hard to maintain the discipline.
Comments
Post a Comment