this post was submitted on 14 Aug 2023
43 points (100.0% liked)
Experienced Devs
4008 readers
13 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Mandatory test coverage was a thing in the past, but later many teams found out that if you are forced to have like 80% test coverage, you end testing framework or even getter and setter tests (at least in Java world). Tests for the sake of tests seems to be irrelevant.
…but, test as a skill and habit is also necessary to some extent. Let's say, you set up mandatory 20% of test coverage (for new code). This shouldn't end with pointless tests (if it's not only configuration, you will make much more coverage just by adding quality tests). If you have people in your team that don't write tests at all, this requirement will get people used to writing tests.
When we no longer need to spend energy on just remembering, that we should do something (to write tests in this case), we can spend this energy on making that thing with higher quality or quicker.
Once everyone in your team is used to write tests, then is a time to start a conversation about quality of those tests, idioms, preferred patterns, aspects of readability.
PS At the beginning of my career the most important aspect of automatic testing was writing unit tests. Then sometimes people were writing some integration tests. E2E tests? What's that? …Only now more and more I sway to the opposite side, that E2E tests are the most important ones and even in a legacy code you may not find a single unit test, but a few E2E tests cover so much. You will hate a codebase without unit tests the same, regardless if there are E2E tests or not. But if you are new to the project, there is at least a chance that those E2E tests stop you from merging code to master if it breaks core functionality. With amount of time put to write those E2E spent instead on unit tests, you won't have this assurance. It doesn't matter that a shared technical component in a codebase has 100% test coverage if it's only a tiny part of core functionality.
PPS If you decide to incorporate mandatory X % of code coverage, take a look at mutation testing frameworks / tools
We use a little bit of property testing to test invariants with fuzzed data. Mutation testing seems like a neat inverse.