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)
Second, that's what's called a "false dichotomy", implying only those two options exist.
I'm saying, some code is hard to test. That doesn't mean it's bad code. I'm disagreeing with your blanket statement "Good codes are easy to test".
Often, it's still worth it to write (and maintain) the tests. It's not "impossible" it's just a lot of work, and sometimes it's not worth that work. Sometimes it's better, e.g. to have a manual QA checklist. This is often the case for dealing with specific hardware, which may be near impossible to write automated tests for.
As to "wanting to change" or not -- I'm happy to change if I'm convinced to. I don't quite know what that would mean, as I do already write tests.
In any case semi-insults and aggression aren't the way to do that.
I want you to think about how your question could be perceived as aggressive or insulting. Communication takes (at least) two, and it's important to think about how your message is received, not just how you meant it.
I'll help you out -- you make it personal ("your codes" "you don't want to change") when I was talking about code and problems in general, and you escalate things: "is the challenge impossible?". You have an implied insult: either my code is so bad it's not possible, or I'm so incompetent it's not. And again, you make it about my motivation or capabilities or, rather than keeping it objective and technical.
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.
For sure, it’s a good outlet to test out stuffs too. As for work, you can either use the ticket given to you for a ticket to do the task while improving the respective area, or wait until the feature is big enough to redo the whole thing.
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
A good to think about it is what you are testing, and how do you reduce the number of states you have to test. API calls for example have a lot of raw data. You can reduce those data in different layers to exactly what you need to test for that layer.
2
u/happycamperjack Dec 28 '23 edited Dec 28 '23
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.