If you’re testing 2+2=4 and it’s not failed in the last 25 years, then it doesn’t tell you anything when it passes.
While that's obviously a rhetorical example, your point is valid. I've seen way too many tests that are testing obvious things that wouldn't fail or things that would be caught simply by linting. The problem is that some managers/teams focus on code coverage and simply think "higher is better". Engineers should consider whether a test is testing something that can break under certain conditions (e.g., unexpected input) or if certain conditions aren't met (e.g., a data contract changes).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While that's obviously a rhetorical example, your point is valid. I've seen way too many tests that are testing obvious things that wouldn't fail or things that would be caught simply by linting. The problem is that some managers/teams focus on code coverage and simply think "higher is better". Engineers should consider whether a test is testing something that can break under certain conditions (e.g., unexpected input) or if certain conditions aren't met (e.g., a data contract changes).