This is merely one instance/example of a deeper principle: avoid mixing layers of abstraction
There is also this gem in the post:
You shouldn’t be mocking your methods, you should mock your IO. And, similarly, you shouldn’t test methods, but rather software functionality
I totally agree! With containers you might not even have to mock your IO but can check if the application behaves correctly.
One is to prevent user abuse the other is to prevent coder abuse.
I work in silicon verification where we do extremely thorough testing, and that is nonsense. It’s perfectly fine to test internals of a system because often it is difficult or impossible to get good test coverage of internal parts of a system just using the public interface.
This is saying if you have a module with public functions A and B, they shouldn’t call each other, right? But it’s not saying that module A shouldn’t call module B’s public functions. That’s what I thought it meant at first, but that seems crazy.
Yes, I read it as the first too. They don’t go into cross-boundaries at all.
I think the headline doesn’t convey the substance of the article, but this is spot on. I just ran into a small, fixable problem my developers had created by doing that just this week.
It was easily fixed, but it shouldn’t have been done that way in the first place.
Removed by mod
Ironically in this case the bug was in the MVC controller and fixed as part of a ports-and-adapters AOP audit implementation. MVC isn’t immune to it. It was a controller endpoint calling another controller endpoint, because someone was doing a bit of business logic there rather than in the service.
Yes, had they implemented MVC properly they wouldn’t have done that. Anyway your point is well taken but as it happens in this case, the deities of irony conspired against you today.
