MaddyI've often read about software engineers who don't like writing tests at all, even when building their own applications.
I get it. The reason for this is that "tests" don't feel like you're actually building something. You're not in that creative state. They feel like an extra, separate activity. For some software engineers, this activity feels like a chore. But it doesn't have to be.
DISCLOSURE: This article contains affiliate links to external products. This means that I will earn a commission at no additional cost to you if you decide to make a purchase. Thank you!
In this article, I'm going to walk you through:
How to start enjoying writing tests.
Deciding what to test.
How the compiler can help you test your code.
Naming tests.
I'm inspired by the book Street Coder, written by Sedat Kapanoglu.
How to start enjoying writing tests
A great way to start enjoying writing tests is to use test frameworks.
I mention this because you can get away without them.
Test frameworks allow you to:
Execute all tests and report all the errors at the same time.
Produce a code-coverage report that helps analyse parts of the code that tests haven't covered.
Run tests in a nonsequential fashion.
Report the nature of any errors.
Deciding what to test
This is a matter that's interesting to address.
What do you ACTUALLY test? Because we test to know whether the functionalities we write work as expected.
✅Respect boundaries
You don't need to test all possible scenarios and combinations.
It would help to identify and concentrate on the scenarios that cause unwanted behaviour.
✅Code coverage
Code coverage tells a software engineer which part of the code is missing tests.
Sadly, 100% code coverage doesn't necessarily mean you've written enough tests to cover the code.
It would be best if you still relied on respecting boundaries.
✅Keep it simple
You don't have to write tests on a piece of code that doesn't exist.
You can apply the Pareto Principle (80/20 rule) in testing.
Some lines of code are more likely to cause bugs done others.
Those lines are the ones that need to be addressed.
Let the compiler test your code
I previously wrote an article about the advantages and disadvantages of the compiler, if you'd like to know more about how the compiler helps a software engineer write better code.
❌Eliminate null checks
Instead of having several null checks, allow the compiler to check the correctness of the code.
Using specific types contributes to reducing the number of tests to write.
❌Eliminate range checks
Using unsigned integer types to reduce the possibilities of invalid input values.
When you use an unsigned type, passing a negative value will cause a compilation error.
A method shouldn't take care of validating negative values.
❌Eliminate value checks
Often I've seen methods having multiple boolean checks—all in one method.
It's nicer to break down the various conditionals into small and separate methods.
This makes writing tests easier. In addition, it makes the code easier to scale and more readable.
Naming tests
Even tests deserve to be named appropriately.
A test should express:
The name of the function you're testing.
Input of the test.
The initial state of the test.
The expected behaviour.
CONCLUSION
I hope you'll now be more motivated to include tests in your applications.
Do you normally enjoy writing tests? Let me know in the comments.
You can get the eBook here.
Thanks for reading my article.
Until next time! 🙋🏾♀️
