Were you surprised when you first heard of unit testing with a framework like Unit? Rather than ad hoc testing, you save your tests and run them as needed. The idea seemed clear to us. With that said, you’ve seen a few approaches to unit testing that you think are flawed.
Here are five, in ascending order:
- Testing others’ code
Although understanding this one is essential as it lays the foundation for larger ones, you don’t need to test one line at a time, but examining an entire function or method can be excessive. You need to understand if there is a way to try less code and achieve the same aim. If the response is “no,” you have a unit test.
- Connecting to the database
Look at the previous example, saveUsertoDatabase. You can see it calling the database connection’s save procedure. That’s not unusual. The issue is the test. You can’t validate an object dedicated to the database by querying it and comparing the returned object to the saved entity.
Even creating a test database that is later destroyed is wrong. Unit tests cannot rely on external services. Consider this: your test will fail if the database connection fails during the trial. So your code is flawed? No. To test your code, you ended up testing the database connection. That’s wrong.
Integration tests, e2e tests, and other tests can accurately test that behavior. We only care about our code. So, only the test needs to exist while your test is running. Mock every database object and inject a fake into your function.
- Multiple tests within a test case
Having methods that do multiple things is usual, and you should keep doing it. But your tests should focus on the “unit” of code you’re testing.
So, if you want to validate multiple things at once to save time and avoid repeating logic and code within your tests, think again. A unit test should only focus on one thing. If the test fails, it should tell you which code unit failed. But if it covers 3 or 4 logic lines.
- After-action testing
Unit testing is a practice that should occur either during or before creating the tested code. Because in both circumstances, you’re considering everything your code can do, every possible edge case, and every possible failure. But if you write your tests after the code is created and deployed, you’re prejudiced.
A code that isn’t entirely written and tested forces you to question its logic. It’s like engineers testing their features vs. having someone else try them. Most likely, the second person will report far more issues than the inventor, who is already prejudiced and testing it as they intended.
- Not updating tests after code refactoring
Finally, good unit testing requires consistency. Like the initial point, if you don’t update your tests’ logic when the tested code’s logic changes, the tests lose all validity.
Testing after a code update is critical since you may have incorporated additional logic routes not covered by the initial test. This suggests the new code is possibly safe, but all it signifies is that you introduced other untested code units.
Code coverage tools let you understand if all the code units in your files have been tested. For example, you can use it to see how to restructure your tests before giving up everything after 20 lines of code.
The above article contains the common unit testing mistakes. So when you perform the same, keep yourself aware of the above errors. Make each unit testing utterly separate from the others.