Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I usually go with:
"Hi, we seem to be missing tests here - as per our code quality guidelines, can you add thorough tests to all non-trivial methods and ensure they pass?"
You can go the route of using automated rules to test if coverage on the PR is above a threshold too, but I usually avoid that as the over-reliance on a number creates way more problems than it solves in my experience. -
Just ask them to test their stuff before pushing or creating a pull request for the main branch.
If it doesn't work on staging, chances are, it also doesn't work on their dev machines.
While tests are in general nice to have, there might be higher priority things to do first.
But with or without tests, some manual testing should always be required before pushing new code to staging.
Humans are bad at testing. But they are even worse on writing good code - and tests like documentation are code too.
Would telling someone in a code review that their code wouldn't even work and that a simple test would have caught it of they wrote one be considered rude? Should I just tell them exactly what the problem is and move on or make them figure it out?
I want people to be testing the code they write but I don't want to just become annoying to them by telling them constantly to add tests when there is no immediate payoff that these juniors obviously crave. Similarly I don't want to antagonise them when they are so early in their career.
question