expect(true).toBeTruthy();

The line of code above may seem like a joke to you, but it isn't. It is an actual line of code I found in a unit test for some code I inherited. And it enraged me.

Why So Serious?

My assumption is that the original coders didn't test anything while developing the application, and when they were held to a code coverage requirement, they cheated. The line of code above is a lie. While they created a passing test, they ultimately were not testing anything that mattered.

It is important to understand that the testing software available today can be fooled to show that tests are passing and that the percentage of code coverage ⏤ the amount of code being tested ⏤ is very high.

People fool testing harnesses all the time, apparently. I have never done this. To me, this is a terminal decision. As in, if I saw this in your pull request, I would stop trusting your work.

Side Note: This Could Happen to You!

Side Note

Be Forewarned: this situation could happen to you. My experiences and the stories I've been told inform me that this scenario becomes more likely when there is a personnel transition.

In my situation, the original coders for my project were an external team of contractors who eventually turned the code over to my company. I imagine there wasn't proper technical oversight with this external team and they were allowed to create shoddy tests.

Similar scenarios include people who are "short-timers": team members who are scheduled to be moved to another team or are leaving the company. People feel like since they are leaving, they can be irresponsible with impunity.

This is not to say that external teams of contractors or team members in transition are always untrustworthy. But without the proper oversight, and without good technical supervision, these transitional scenarios can create large ledgers of technical debt. Always audit code delivered in these scenarios and hold developers accountable. When you do not, the responsibility for this technical debt will be passed on to the next team or developer, increasing the cost of that code.

From a developer's point of view, I like to "pay it forward." You should always write code as though you will be the developer assigned to maintain it.

The Importance of Testing

I am not one of those Test Driven Development (TDD) zealots. TDD is cool. I know many people who live by it. I simply haven't gotten into the rhythm of create the test, create the code, update the code, update the code... until the test correctly passes.

The point, to me, has always been no matter how you get there, test your code. All the testing ⏤ manual testing, unit testing, integration testing, end-to-end testing ⏤ should be planned and implemented on every project for every feature.

Automated testing is an important part of the development process. When done properly, it ensures that the code will perform predictably as written. When code is updated or features added, tests confirm that the changes aren't going to produce defects.

With reliable tests, development and deployment becomes somewhat predictable. Without them, anything can happen.

Why Cheating on Testing is Bad

Testing provides confidence at every level of product development: developers can be confident their code will work when deployed, business analysts can be confident the prescribed business rules will be observed, and product owners can be confident the users of the product will be properly served.

When developers cheat in their tests, it creates unknowns. Will the code deploy? Will the code work as expected? Do the passing automated tests match the manual testing results? Will users be exposed to poor performance, errors, and unexpected product behavior?

Cheating on tests means a breach in confidence. That breach can be expensive and that expense can take the form of work hours, stress, poor employee performance reviews, and employment "adjustments". The worst expense is losing users. Anything that prevents the people who are using your product from being productive and successful is pure expense.

Everyone knows that lying is bad. This kind of deceit is inexcusable. By creating tests that don't really test anything, you are documenting your apathy toward your co-workers, future maintainers of your code, and any users of your product.

It crushes confidence and saddles any future development of this code with an unimaginable weight.

How to Avoid This

You can avoid getting yourself, your team, and your company into this situation:

  • Support Your Organization: Ensure everyone in your organization understands the importance of testing.
  • Support Your Team: Ensure that testing expectations are very clear and that the team has adequate time to create proper tests.
  • Take a No Tolerance Stance: Inform your team that deceptive tests are unacceptable.
  • Harden Your Pull Request Reviews: Ensure that reviewers and approvers of pull requests for your project know how to spot deceptive tests.
  • Provide Proper Oversight to External Teams: Give an external team the same oversight and technical supervision as internal teams. Require code reviews from internal team members on pull requests from external team members.
  • Set Expectations for Transitioning Team Members: Ensure that team members who are to be leaving the team understand that expectations of the quality of their code hasn't changed and are identical to all team members.

In Conclusion

Don't be a lazy developer. Don't cheat. Be aware of how your actions affect others. Don't rob anyone of the hours of effort they are required to correct your deceptive tests.

If you have had deceptive tests dumped in your lap, remember it. Never make anyone else feel that despair.