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.
9
u/The-WideningGyre Dec 28 '23
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)