4 ms·
>That is great argument for why full coverage is nonsense. Why would you test getters, setters and constructors if they do little? Errors and code changes can
by crimsonalucard 9y ago
>That is great argument for why full coverage is nonsense. Why would you test getters, setters and constructors if they do little?
Errors and code changes can happen at anytime and anywhere and in places you never look. You have full coverage for full safety.
>I read and understand both just fine. Moreover, second one must have a place where equivalent of config and client objects go - but I dont see where it is. Or, you added do-nothing config and client objects go to OOP example to make it look worst. OOP example also have address twice, subject twice and message twice.
The function doesn't need a config object or a client object because those are patterns and abstractions that are unnecessary. That is the point of the article. Patterns that are blindly followed religiously and abstractions used in a way that is excessive.
>The trouble is, that readers dont see it.
It's not possible to speak about what other people see. You can only speak to your own intelligence which is the only logical possibility here.
>The point of functional was analogy.
The point was that you think functional and oop are just two different styles of programming that are both equal and good. This is incorrect. One is better than the other but at the end of the day I wasn't even comparing those two styles.
- watwut 9y agoWhich patter requires config object and client object for send mail functionality? I read a lot about them and there is none. So, unless you can name it, you are making stuff up. It is not even about abstraction. I can write func send_mail(msg: str, subject: str, address: str, from: str, server: str, port: num, <following 20 config variables>) and have procedural code with same functionality. Writing test for every getter and setter will not give you safety at all. This sort of test is completely pointless.