4 ms·
Google API libraries mark every class as "final" so it's not trivial to mock-extend it for tests. But third-party IO is exactly the thing you'd want to mock. P
by deepsun 10mo ago
Google API libraries mark every class as "final" so it's not trivial to mock-extend it for tests. But third-party IO is exactly the thing you'd want to mock.
Probably because they zealously followed "Effective Java" book.
- wiseowise 10mo ago> But third-party IO is exactly the thing you'd want to mock. You write an adapter.
- deepsun 10mo agoNo, some other library classes accept only their own, not my adapter. Not mentioning of course needless copy-pasting dosens of members in the adapter. And it must be in prod code, not tests, even though it's documentation would say "Adapter for X, exists only for tests, to be able to mock X".
- wiseowise 10mo agoYou wrap whole 3rd party dependency in an adapter.
- akoboldfrying 10mo agoThat's a lot of upfront work and maintenance, not to mention the friction of needing to mentally translate every occurrence of OurFooAdapter to Foo in order to find documentation.
- wiseowise 10mo agoYeah, well, good code takes some thought to produce. More news at 11.
- deepsun 10mo agoThe second argument still holds -- all those wrappers will exist in prod only for tests. Moreover, that wrapper library is now a pretty large piece of code, and we'd want to maintain and test as well. But cannot without hacks.
- throwaway7375 10mo agoOnce you start writing adapters you need a way to instantiate them to choose between implementations, and factories is often used for this. Then you might generalize the test suites to make the setup easier and you end up with the infamous FactoryFactory pattern.
- deepsun 10mo agoI think it's easier to unpack/remove-"final"/re-compile the library .jar during the build time. Will be more stable to any changes than an adapter.