CAll Us: +1 888-999-8231 Submit Ticket
The Business Case for Testing Your Code

The Business Case for Testing Your Code

We’ve talked a bunch about writing tests for your WordPress code, but one thing we haven’t touched on yet is why you should spend the extra time and money to write them. If you’re a manager or business owner, why should your developers ship features a bit slower as they take time to write tests?

Testing as an Investment

Today we’re going to tackle that management question. I want you to start viewing testing practices as an investment instead of an expense to your business.

Reduce Regressions

How much do you like it when your site breaks? If you’re like me, you hate it. I’m betting that at some point you wonder how on earth your developer could break the site. They must be terrible…right?

Wrong.

They’re just human like you and they make mistakes.

Good testing strategies can stop your projects from breaking. When you’re writing code and running tests, a good test suite will show you when something breaks. Then you can fix it right away when the work is fresh in your head.

Good testing can also cut down on debugging as you fix issues. Instead of wondering where on earth a problem is happening in the code, a failing test can show you where exactly you need to look. 

For those times you do find old bugs that break stuff, writing a test to catch this scenario means that in the future the code won’t break in the same way. No more chasing a bug around thinking you’ve fixed it. Good tests will tell you that the bug is squashed.

Deployments Are Easier

There was a time when I refused to deploy client sites on Thursday or Friday because I didn’t want to work on weekends. Two things fixed this issue. First, a repeatable deployment process let me know that I couldn’t mess things up with some silly FTP error. Second, writing tests let me know that my code didn’t affect anything else on my client sites that needed to work.

Now you’ll find me deploying code many times each day, even on Friday afternoon.

For clients, that means they don’t have to wait till Monday for a feature to release, if we get it approved on Thursday. My clients are happier because I can ship features as soon as they’re ready to go.

Changes Become Easier

Have you ever worked on a project where some portion of the code was a black box that one person knew about, but who didn’t work there anymore? You’re terrified that if you even think about touching this code you’ll awaken the Kraken and lose a month of your life as you wrestle a mythological beast back into submission.

Good testing stops this from happening.

When you have good test coverage, anyone can swap in and work on a part of your system. When anyone can work on the code in your project, you’ve decreased the risk to your business because you’re not reliant on that single developer who can manage the Kraken.

This also extends to changing out big parts of your system, like the database you choose to use. If you’ve got a good test suite written you can change the layers of your application independently and know that they’ll still interact properly because your tests pass.

Tighter Developer Feedback Loops

It’s far easier to fix issues that have just been created. Curtis of 6 months ago must have had no idea what he was doing, because I’ve seen that code and had no idea what was going on. Writing decent tests can prevent this from happening because you find those bugs as you’re writing code instead of stumbling across it months later. Instead of trying to find the same mind space you were in months ago, you’re sitting in the code, fully understanding it and ready to fix any issues that come up.

The Only Thing Developers Write Less of is Documentation

I’ve looked at lots of code in my career and spent lots of time trying to figure out what on earth is going on with some websites I’m working on. If there is one thing developers write less than tests, it would be good documentation. Sure many say it’s important, but very few write any documentation at all.

While I’d love to say you need to write both tests and documentation, I’d settle for tests because they act like documentation.

When I take over a project with tests I can easily jump into the project and start writing code without hours spent trying to figure out what is happening. I know that when I break something, the tests should tell me I broke something. If I find an issue later, I add it to the tests, thus adding to the documentation on how the code should be working.

Tests make it easier for any developer to pick up your project without you needing to worry that everything will get broken because they were not the ones that have worked on it since the start.

Improved Reputation

The reputation of your business is everything. If you have a reputation for shipping good work on time that doesn’t break, then you’re going to get more work. Testing can help you build this reputation.

Instead of breaking code as you “fix” things, you’ll see a failing test and fix it before the client knows there was an issue. Happy clients refer new clients, who can, in turn, become happy clients.

When you step back and think about it, your job isn’t to simply write code for customers. Your job is to write code that works to fulfill the needs of customers. When you add testing practices to your workflow you will be able to deliver on that better.

Your code will break less. You’ll be able to ship working features more often.

Your customers will be happier as you serve them better.

Stop making excuses and use testing practices to provide a better service to your customers.

Source link