I've often read about software engineers who dislike writing tests, 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.
Decide 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
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.
Passing a negative value will cause a compilation error when you use an unsigned type.
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.
Breaking down the various conditionals into small and separate methods is nicer.
This makes writing tests easier. In addition, it makes the code easier to scale and more readable.
Related: What is "Code Refactoring"?
Naming tests
Even tests deserve to be named appropriately.
A test should express the following:
The name of the function you're testing.
The input of the test.
The initial state of the test.
The expected behaviour.
Conclusion
I hope you'll 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! 🙋🏾♀️