2 ms·
These seem like a great way to write simple, high-performance code that is easy to write (because you just think about your actual problem vs. what someone who
by henning 5y ago
These seem like a great way to write simple, high-performance code that is easy to write (because you just think about your actual problem vs. what someone who wants to ignore the problem wants -- what arbitrary slice are they expecting your code to cover?) and easily tested with simple integration tests that use quality fixtures which exercise your code thoroughly.
Endless classes of bugs eliminated through these "anti-patterns".
Guess what: if unit tests pass in an OO system, it doesn't mean a fucking thing, especially dynamic languages where simply changing a name in a large codebase is a risky operation.
And fuck virtual methods.
- shoo 5y agoif i could only afford a single test, i'd much prefer it to be an integration test rather than a unit test. but, some kinds of code can permit a huge number of execution paths with different behaviour and interactions that need to be tested. If you want to cover all the different paths using only integration tests without decomposing a system into simpler subsystems that can be tested more locally, then you end up with a combinatorial explosion in the total number of execution paths and the number of test cases you have to write and maintain.