Member-only story
3 Tips to Write Good Unit Tests for Your Team
Your tests failed. Again? There was no bug. You changed an implementation detail, and your app still works, but your test is broken. Is unit test worthless?
Software engineers hate writing unit tests.
Despite how annoying unit tests are, we all know that unit tests are good for creating a robust, well-functioning system. It is one of the most valuable types of automated testing.
By definition, a unit test is an automated testing method that tests the behavior of your function.
A unit test should be independent of other test results. They should be able to run on any platform or machine. You should be able to take your unit test executable and run it on your mother’s computer when it isn’t even connected to the internet.
If you are a software engineer, chances are you will touch a unit-tested system. Even when you get a green check mark after running test suites, the test suites need to be properly created, or it can result in fake positives.
Many teams need to learn how to conduct proper unit tests; some don’t see the value of creating them. For instance, many engineers only test the happy path of the function but need to account for the unhappy or complicated test cases.
In this article, we will discuss best practices and gotcha’s for writing a good unit test so that your team can reap all the benefits of unit testing.
Write Your Test Suite Based on Behavior Instead of Implementation
Test maintenance is one of the main obstacles for teams trying to adopt unit testing.
Engineers are often annoyed; development becomes very slow when test suites are too fragile and fail when they slightly change or refactor the codebase.
Do breaking test suites caused by a slight change in the codebase or refactoring represent fragile or robust test suites?
The answer is it depends.
Testing based on implementation makes test suites very hard to maintain. Moreover, you will get false negatives just by trying to change…
