Last week I wrote about an elegant way of dealing with RxLifecycle lint warnings. This time I wanted to offer some words of advice on writing (and maintaining) tests.
We all know you should write tests. It’s drilled into many of us from a young age, but do you really know why? Have you ever experienced what happens when there aren’t good tests in place?
A little while ago I was asked to jump onto a project that I had worked on previously and fix some bugs. This project had extensive tests (both unit and UI types). When I restructured the code to fix the bugs and ran the tests, I discovered that a large number of them were failing. So, I backed out my changes and ran the tests again — still failing. Uh-oh. I had just been bitten by the worst kind of test — ones that are out-of-date, and are therefore useless.
I think the following gif sums up the dangers of this pretty well (having unit tests but failing integration tests):
In the long run, fixing these two little bugs took me several weeks to fix, because my colleagues and I had to fix all of the tests first.
Everyone has their own reasons why they don’t write or don’t fix tests. It’s a dynamic and challenging world — it happens. But, what can we do about this?
I’d like to offer the following suggestions:
Always make a best effort to write tests when writing new code. If you say “We didn’t include time for writing tests in our estimates”, then you should start doing that! As a developer, it’s your responsibility to help your project manager/client/etc. understand the importance of having tests — so be brave and speak up about it!
Writing tests gets easier if it’s part of team culture. So, when you review a PR, always think about the tests. Was enough new code created that there should be new tests in place? A PR review is an ideal opportunity to point out missing tests. Over time, everyone will get used to writing them and you won’t have to bring it up as often.
Make sure running tests is automated. If you have tests, the unit tests should be run for every PR, and if they fail, the code should not be merged. It’s understandable that UI tests may take longer to run — I find that running these nightly is a pretty good cadence. Each developer should be running them before submitting their PR though. And, when they break, make time to fix them.
If you really are up against a tight deadline and don’t have time to write tests, file a ticket in your issue-tracking system and put a TODO comment in the code that relates to the areas that require more testing. This way, you at least have a record of what is not well-tested and this technical debt can be prioritized and eventually worked on.
Deliberately not writing tests should be a team decision. If you’re feeling pressured and behind schedule, talk to your project manager/tech lead/etc. Don’t decide on your own you’re going to stop maintaining the tests — that’s a decision that everyone should be aware of and help make.
Do you have other words of advice you’d like to offer when it comes to writing/maintaining tests? Leave me a note in the comments below! And, please follow me on Medium if you’re interested in being notified of future tidbits.
This tidbit was originally delivered on March 29, 2019.
Top comments (0)