I LOVE automation.
It's just so cool. And it helps me be incredibly lazy.
Dishwashers, Dryers, Self-driving cars (although I'm not quite rich enough for that one yet).
Say what you want about lost jobs and such, but automation sure does take the mundane work out of our lives.
Maybe that's why I like automated testing so much. Manual testing is just such a bore. And when things are a bore, I have trouble doing them well.
True story: I was doing poorly in my 7th grade math class and my teacher noticed. Rather than punish me for it, she suggested I take on a greater challenge and move to the honors class. It's a little bit of a humble brag, but it's also to say that my mind just sucks at mundane tasks. Give me a challenge or some tricky problem to solve and I'll be 10 times more motivated.
On that note, I think automated testing is great, because it keeps me from having to test the same boring thing again and again.
But...
I've heard from many folks (and have even said myself), that "I wish we did test automation". If you wish you did something, why don't you?
Well, I asked twitter, and the response I got back was pretty insightful.
The number one reason is "I don't know how to start".
Oh, I totally understand that one. Here are just a few questions that can cause confusion for someone new:
- "How do I write tests?"
- "What do I test?"
- "How do I run them?"
- "When do I run them?"
- "How do I fit them in each sprint?"
With all these questions, it's no wonder we struggle to get test automation in place. And here's some further tough realities of testing to add to the stack:
- Getting set up can be really complicated (e.g. integrating in to build systems)
- On that note, boilerplates and trivial demos don't help because there's always an edge case you run in to
- It's hard to feel the benefits right away
- You have to figure out: "what am I testing for?"
- Tests require extra work to keep going
- You don't get paid to write tests and tests aren't normally included in the sprint planning session.
This test automation stuff doesn't seem so rosy now, does it? If tests are so complicated to get set up, then why do we think we need them in the first place?
Well, aside from being able to be lazier (which is a tough argument to make in front of upper management, believe me), I know for a fact that there are at least three definite benefits to testing:
- Writing tests requires you to validate assumptions about your code and your project's requirements
- Writing tests is mega-difficult to do if your code is tightly-coupled, so it provides extra motivation to write code that's easier to maintain
- Writing tests is a form of self-documentation, and every test you write makes it easier for someone new to join your project
Notice how I haven't even mentioned anything about it catching regressions? It turns out, writing tests has just as much to do with improving code quality as it does with actual testing.
Next time you need to convince yourself, your boss or your project manager that tests are worth the investment, just know that unit testing:
- Reduces outage time and unexpected functionality, because you'll know your codebase better and will be able to solve complex defects faster
- Reduces upkeep costs, as your loosely-coupled code won't require as much maintainence over its lifespan
- Improves future velocity when it matters, as bringing on a new team member late in the game will be more effective
And for yourself, you'll be happier knowing your days are spent writing more code, instead of testing the same functionality again and again and again and again... ugh.
Further Reading:
- You Are Not Paid To Write Software by Derick Bailey