Unit tests are something that engineers write to test the work they’ve done in smaller pieces. Code that is tested tends to perform closer to expectations. Future changes to old code protect the way things work by causing unit tests to fail if something is changed unexpectedly. Passing tests are green checks ✅. Failing unit tests are red Xs ❌.
Default behavior is to write your unit tests after you’re done writing the solution. When an engineer sees all ✅, they call it a day and ship it. The funny thing with unit tests are … they are also subject to being full of problematic logic or buggy code. How does the engineer know their tests are correct or cover all the scenarios if you’ve never seen a failure?
There is a concept from test-driven design (TDD) that helps mitigate this. Write your tests first before writing the actual solution. Your tests will all start with ❌ and you’ll slowly turn those to ✅ as you write the solution.
Feedback
I was chatting with a coworker today and gave this analogy of unit tests being like feedback. How so?
If you receive feedback from a lead and always get positive remarks ( ✅ ), how do you know if the lead is actually seeing your work enough to find any areas of improvement ( ❌ )? I’ve found that feedback feels less impactful unless once in a while you get something constructive or critical to work on.
I figured the analogy was kind of neat and figured it might illustrate the importance of feedback being a system of trust. You can’t trust your unit tests until you’ve seen other than just successes. And likewise, receiving only praise can make someone feel uneasy and possibly not trust they’re getting the whole picture.
