7 ms·
A common pattern to get around this situation is to use mocking frameworks to fake those calls without using interfaces. It’s in the air whether this is better
by t-writescode 7y ago
A common pattern to get around this situation is to use mocking frameworks to fake those calls without using interfaces. It’s in the air whether this is better or worse in the general lifespan of a piece of code; but, there are alternatives.
- taco_emoji 7y agoHow does that work in a static language? In most (all?) static languages, you'd need an interface or virtual method in order to on-the-fly generate a class that implements the mocked functionality.
- chinhodado 7y agoNot entirely sure what you meant, but in Java/C# you can easily mock out a concrete class with a mock library, like Mockito. No interface required.
- GordonS 7y agoThere are plenty of mocking frameworks for C# (Moq, FakeItEasy, etc), but for all but the most trivial classes, you generally need to use an interface or mark methods as virtual. It's one of the reasons I tend to minimise my use of mocks as much as possible.
- chinhodado 7y agoIt's the same with Java where it's very hard/not possible to mock final methods. It's just that methods in Java are virtual by default so it's less "in the way" when you need to mock something.
- apta 7y agoWhat do you use instead of mocks when testing?
- GordonS 7y agoReal instances of the dependant class. A "unit test purist" would likely shun this, but I take more of a realist approach; in many real-world cases, mock-heavy tests make for brittle tests that don't give confidence of correctness. I tend to focus on integration tests, as I find these provide the most value while still executing very quickly (depending on the stack, obv). That doesn't mean I don't use unit tests, or that I never use mocks - I just use mocks very sparingly.