Saving time by skipping unit tests, the misguided guide to software development
Unit Testing despite it’s origins in Extreme Programming over 20 years ago, and the pervasiveness of Agile Methodologies in Software Development management, is still viewed by far too many developers and managers as unnecessary burden on the development process not as an essential part of it.
I’d argue that Agility is not possible without good automated test suite. The first two Principles behind the Agile Manifesto are impossible to deliver without good automated test suite.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Change is painful process without an automated way to verify the correct functionality of the software.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
In order to deliver working software frequently one needs a way to first verify that it is working before you can deliver it. A large portion of the traditional software release cycle is consumed by manual QA, by automating a lot of that work we can get that cycle time down to something that one could term frequent.
Unit tests form the automated testing pyramid, without a solid base of unit tests any attempt to automate the QA process becomes brittle and error prone.
Clearly, Agile Software Development is not possible without automated testing.
Saving time by skipping unit tests is like getting a loan from a loan shark to pay for your technical debt. It may get you out of a tight situation but over the lifetime system the interest payments on that technical debt is going to be many multiples more costly than the initial additional cost of adding unit tests in the beginning.
It is a fallacy to believe that skipping unit testing to meet deadlines will help the project to be delivered on time. The effort saved from writing unit tests in the beginning is spent many times over later in the development cycle when the inevitable changes get stuck in an endless cycle between QA and Dev.
Unit Tests are the basis of any Agile Practice
Unit Testing forms the structural foundation of key Agile Principles and their supporting practices.
- Unit tests enable collective ownership. Individual code ownership is not required if all classes are guarded by unit tests.
- Unit tests enable refactoring, unit tests can verify that a change in structure did not introduce a change in functionality.
- Unit tests enable continuous integration.
Without a strong culture of unit testing as part of a teams commitment to technical excellence, your Agile Practice is doomed to failure.
Okay! We’re doomed.
Too many teams when presented with the facts, throw up there hands, come up with a million reasons why unit testing won’t work for their situation and continue on the slow march into oblivion.
I call bullshit!
Like any new skill at first it is difficult but with practice it becomes second nature. Just as coding felt impossible in the beginning with practice those cryptic error messages start to make perfect sense. And only with practice can we get better at it.
Following Uncle Bob’s benefits of Test-Driven Development:
Debugging. What would programming be like if you were never more than a few minutes away from running everything and seeing it work?
Courage. Nothing makes a system more flexible than a suite of tests — nothing. If you have a beautiful design and architecture, but have no tests, you are still afraid to change the code.
Documentation. Tests are small, focused documents that describe how to use the production code. They are design documents that are written in a language that the programmers understand; are unambiguous; are so formal that they execute; and cannot get out of sync with the production code.
Design. In order to write your tests first, you have to decouple the units you are testing from the rest of the system. There’s simply no other way to do it. This means your designs are more flexible, more maintainable, and just cleaner.
Professionalism. Given that these benefits are real, the bottom line is that it would be unprofessional not to adopt the practice that yields them.
Now TDD may be a little out of favour these days with some prominent proponents expressing some more nuanced views recently. However those statements are equally valid whether the test is written before or after the code is written. The important thing is that the test are written and run regularly to verify the correctness of the application.