I’m overwhelming myself again - I do it often, I have it down to a science. This time it’s with Test Driven Development. Did you know there are some zealots who say that you shouldn’t write a single line of production code unless you have written test coverage for it already? 😓 That’s intimidating! Even if you know how to write tests, there can be a few things that hold you back from writing them first.
Writing tests for starters
The easiest way I’ve found to think about tests is that you are verifying your expectations. You probably already do a lot of testing using your console or var_dump, looking at variable information wondering what the heck the value is and why it’s not what it should be. Automated testing can do the same thing but way faster, and can verify that information for you not just once, but every time you make a change.
Coverage for starters
You only have to write tests for your code. If you’re testing code written for WordPress, you don’t test your calls to WordPress APIs - you trust that if you call those functions with correct arguments they’re going to work. Testing WordPress Core isn’t your job.
You can apply this to any framework you end up using, or even external APIs you expect to integrate with. This is why you’ll often find that mocking those functions or data returned from third parties is an important part of writing tests. Your automated tests are for your code. You test it in isolation.
When you’re just getting started with automated testing, and especially if you’re trying a new framework, it’s going to be hard to tell the difference between what is truly your code and what doesn’t need coverage. Go ahead and write your production code, try to think about whether it’s really yours as you go. If it is, and it’s returning values you expect to take a certain form, now’s your chance to write a test. If you’re reaching for console.log or var_dump stop right there and write a test.
Writing testable code for starters
You might isolate your code from third party APIs, but are you sure it’s adequately isolated from itself 😰
If you haven’t kept your code DRY, or SOLID enough, a class or method could have multiple points of failure that are unreachable for testing. Hey, it happens! Hammering out a program for one particular implementation is a bad habit but it helps meet deadlines (at first).
The point is that testable code isn’t just isolated from the outside, but that the pieces of the program are also adequately isolated from each other, and from the business logic of your particular use, that they can be tested on their own.
When you’re starting out, you won’t have the intuition to know the best way to structure your software. Thinking like a software architect takes a lot of time and practice. When you find that you can’t test parts of your code, though, it’s an opportunity to learn how to restructure your program in a testable way. It’s a road towards software composition.
Tao
If I can find it again, I’ll link an excellent Stack Overflow answer to the question of how many unit tests to write. The answer is different, depending where you are in your journey as a software developer.
As a novice, just write some. Focus on the quality of your tests, not coverage. You’ll notice when you need to write tests, because you’ll be inspecting variables yourself. Let the computer do the heavy lifting for you instead. That’s what they’re there for.