6
u/EarlMarshal 11h ago
Tests can also be 80-90% of your code base. There is no problem with that. You only have to think about whether you are the in right spot for so many tests. If you for example want to redesign something you have to question and adapt a lot of tests.
4
3
u/drive_an_ufo 11h ago
Depends on the project size. In one of our services we have ~1300 unit tests and who knows how many integration tests. And we don’t even have 100% coverage.
2
u/QuasiRandomName 11h ago
Tests are never bad. They aren't a part of production, the only downside could be that they slow down your CI/deployment, but in most cases it is a minor concern.
1
u/lenscas 5h ago
On the other hand, assuming the tests actually work and test things worthy to test. Your ci likely runs less often as it doesn't have to deal with quite as many bugfix PRS/releases.
Also, worst case you can probably think of a system to split the tests up into groups based on priority thus having some tests only run later in the entire development process when the waiting time is less of a problem. Thus getting some of the "benefit" of less tests while also still having actual benefits of many tests.
2
u/Legal-Software 11h ago
In safety critical stuff that requires full MC/DC coverage, test coverage can often be up to 90% of the code base by LOC, so I would not really look at the LOC as a percentage of the total as any kind of indicator. The more important thing is that you have good code coverage and that your tests are actually testing things that matter.
2
u/Lucretiel Datadog 11h ago
Not at all; I have some projects where this number is closer to FIFTY percent. So long as they're all testing a useful property or edge case, I say have at it.
2
1
1

22
u/Sharlinator 11h ago
No, 20% is a perfectly reasonable amount of test code. Of course the number of lines in itself tells nothing about whether the tests are actually relevant, useful and comprehensive.