Manual unit testing is like filing taxes every year – boring and unavoidable!
It is the most boring ritual ever. Collecting W2’s, bills, and lengthy filling forms.
Yuk, easily the most avoidable too.
How many times have we written code and never tested it? Never.
How cumbersome is it to run the whole application to check a small line of code change? A lot.
We write code, test it and refactor it. We repeat this till its all good.
Isn’t this boring? Yes.
Isn’t there a better way? Yes.
Automated unit testing.
Automated unit testing enable us to automate boring tasks like unit testing.
Everyone knows that!
Then why can’t we start writing automated unit tests?
Well, it can be boring to write automated unit test as much as doing manual testing.
Why make our jobs worse then?
The benefits of having automated unit tests outweigh the boredom.
A little bit of history –
5 years back when my company was transitioning to Agile – We were told to deliver code in smaller increments and frequently.
How small? – Small enough to be minimally viable.
How frequently? – 2 weeks. (No way).
We felt that was not going to work for us.
How would we deliver a feature change in 2 weeks?
How can we break down a feature into smaller pieces?
What will end users do with half-baked features?
Those questions bothered us in the beginning of the transition.
We were also told Agile not only means delivering fast – but reacting to change quickly. And to react quickly, we would have to write code and test faster (frequently).
But how could we do it fast without spending crazy hours at office? We were all used to waterfall model so much, it din’t make a lot of sense.
Worse, in one of the poker estimations – testers on the team started throwing exzuburent hours on tasks. All in the fear of the uncertainty.
They assumed faster pace means more bugs, and quoted more time for testing, verification, and regression. It was required for developers to complete their coding and integration by 6th day (out of 10 business days) of sprint – just so testers could ensure code quality. Early code freezes left very little time for developers – causing stress.
Regression testing and verification was getting on everyones nerves. There were lots of blame games.
Who could be blamed for broken code?
Developers ? because we did not account for existing functionality.
or Testers? because they could not find broken code.
Agile without Automated unit tests felt more like filing taxes on your own – stressful, and confusing.
4 major benefits of automated unit tests.
- Better code quality.
- Faster Debugging.
Maintainability comes from the ability to churn out code without breaking existing functionality.
Automated unit tests in Agile environments guarantees confidence – for everyone on the team.
They allow developers to focus on business, and come up with creative solutions. Testers can focus on functional defects instead of minor technical bugs.
2. Better Code quality.
Code quality is the measure of the accuracy of code meeting functional requirements. The closer the better.
Because defects are automatically detected early with automated unit testing – it is easier to pace forward.
Overall time taken for development is lesser even after accounting for regression, and quality.
Running a single unit test function to debug is faster than to run your complete application.
Debugging with automated unit tests is like using GPS for navigation. It is the turn-by-turn navigation of writing code.
You arrive on time. You know exactly when to exit a highway. No more paper maps. No more pitstops to re-check your route. Best of all, no more asking strangers for directions.
Debugging can be complicated and slow in multi-tenant applications. Imagine how much time it takes if you have to run 4 applications simultaneously to test an small change.
With automated unit test, you run exactly the unit test and debug even the smallest function. It is very convenient this way.
The above is a unit test method name. Does this convey anything? Ofcourse. It states a business functionality “Orders require customer address”.
That’s a documentation by itself.
This sort of information will help new persons on the team transition faster.
1 last thing (maybe most important)…
One question that’s on the minds of everyone new to automated unit tests.
Who will test my unit tests?
How will i ensure my units tests are trustworthy?
Will we need another person to verify my unit test?
If yes, isn’t it same as asking for testers?
Well, not always. There are ways around this. You may not even require another person or tester to verify your unit tests.
You can be your own tester.
Okay, that means aren’t we back to the same situation? Developers doing testing? Isn’t it equally scary?
TDD – Test driven development approach helps us by testing unit tests.
In TDD, we
- Start by writing our unit test (failing) first.
- Then we write production code just enough to pass the failing tests.
- Then we refactor our code (if we have to).
By writing our failing unit tests first, and passing them with production code – we are testing our unit tests.
Is TDD ‘too good to be true’?
Like any other approach, automated unit tests or TDD have their own share of problems.
Biggest problem is ‘teaching an old dog new trick’.
It is very counter-intuitive for the senior programmers to unlearn and learn this new approach. Somehow writing Unit tests without production feels like writing with white ink on whiteboard – Invisible.
Like playing new video games, there is warm up time in getting used to TDD.
It takes more time to develop software with automated unit tests.
However this is like a real-estate investment. It will pay itself off in the long term.
Automated unit tests enable code confidence in IT teams by letting us all focus on what matters the most – Business.