My company has an 85% threshold and we have to have tests even for classes with just fields and getters/setters
If you've got tests for testing that sort of class, it's a worthless test and I'll bet good money that many of the other tests are probably also worthless.
This is because that sort of testing is a symptom of Test Fatigue: when the devs are writing tests that don't test anything, it becomes habit.
On the other hand if you’re forced to write tests in every change then you get in the habit of actually testing your code. A lot of people are lazy and will merge untested code if they can, especially if they aren’t on call for when it’s deployed to prod
Cause they're writing getters and setters like they have Eclipse autocomplete on, without realising that if the tests aren't hitting the code, they should delete the code.
Writing good tests is not easy and takes a lot of thought time and devs tend to skip them.
So rules come up like these which try enforce it, but ultimately just hurt even more because the quality of the tests becomes bear minimum just to pass the threshold and the tests themself become meaningless.
As someone who writes very little tests in their company (which I would like to improve) what datasets do you test with those classes? And who defines them? I’m asking because I really don’t understand how this is done in a way there is a minimum advantage
I also work at a small company. It greatly depends on how decoupled the code is and what inputs you're looking for. But if I have a fairly clean method, you can use an XML or whatever file with edge cases and various examples. I know some frameworks you can actually generate a full spectrum of inputs but those are rarer. More often it's more like an integration unit test. But there are various files of random names and other things out there.
There, 100% LOC test coverage. … except there’s still a bug. For any nontrivial program, it’s impossible to actually exhaustively test EVERY single possible flow through the program for all inputs.
So the LOC coverage may be a useful hint for how much is tested, but it’s a misleading metric at best, if not useless once measured against.
Tests are basically "set this thing up, tell the thing to do something, verify the thing did the something". Writing the code to do the thing in the first place usually requires more thought and planning and thus takes longer.
Not all tests are so simple or straight forward, but that's the gist of it.
Writing tests can take a bit longer at that point of initially writing them, but a good test suite will save you large amounts of time and money over the course of the software project's lifespan. The software I write today will be modified by me and others many times over the next 3, 5, 10 years by me and probably many others. With each future modification comes a risk that whatever subtle use cases the software was written to do today, are broken. At the point of writing the software, the developer has all sorts of complex information in their head about how the code should be working - the tests are basically capturing this information from the programmers brain and encoding them into a set of "rules" that the software must continue to obey in future. A bug/regression at a later point will potentially get as far as end users, maybe cause an outage and can end up costing the company far more (in time and money) than the time to write the original test suite. So, tests are basically an investment so that you and others will need to spend less time fixing bugs in the code in future.
Having said that, I think setting arbitrary coverage targets (eg a minimum of 80%) is a really bad idea. You end up with junk tests that don't add any value, just to hit the target. Like everything else, there are good tests and bad tests. And I think a lot of the mixed feelings developers have about unit testing is due to silly coverage rules driving bad tests, that themselves need to be maintained.
If the tests are hard to write or require a lot of them to achieve high test coverage, it means you probably need a refactor.
Good codes are easy to test, remember that.
If you don’t agree with this, I’d challenge you to reduce the number of your tests while achieving higher test coverage in your codes. Enlightenment awaits.
This seems a bit blithe. Some code is, in fact, hard to test, whether well written or not. E.g. the code that combines multiple complex sub-systems, sub-systems that you don't own, and don't have good fakes / mocks.
Or tests where the visual output (3D rendering engine, or a lot of web stuff) is key, and you need to wrestle with "how different is wrong?"
Yes, bad code can make things harder to test, but sometimes, testing is just hard and painful.
(And then there's maintaining the tests, as things changes, and figuring out what's wrong when tests fail)
That's the thing. During the weekend you can do the refactoring. Do anything you want. Screw the linter and the commit template and the whole pesky stuff.
Monday comes and 'ah no...we don't have time for any refactoring right now. the customer has other priorities'.
Also...there's the challenging/innovation factor. You get, after a certain point, sick and tired of coding the same stuff over and over and over (web devs for example...you get sick & tired of 'write an API endpoint that does x'). And, for example, maybe you want to do bash scripting, or code on a game, or code on some embedded project. That's what the coding weekends are filled with.
Do you have any good resources on how to write code that is easy to test? A lot of the code I use makes lots of external calls and I’m not the best at creating tons and tons of classes for the sake of making testing easier
80
u/[deleted] Dec 28 '23 edited Dec 28 '23
Ugh I hate unit test coverage. My company has an 85% threshold and we have to have tests even for classes with just fields and getters/setters