Sometimes the enterprisey-java-y stuff is actually useful :D You have teams of lazy programmers trying to manage separation of concerns (laziness, hubris and impatience being the three noble virtues). Also if you make the API a class, you can inject the dependency during startup or setup, so it doesn't pollute your API calls in the individual tests. Faking the entire 3rd party API becomes easier if your third party uses something like Swagger or OpenAPI. Failing that building the fake means you are deliberately learning how the third party API *actually* works instead of how it's *documented* to work, which is incredibly important. Then you can start doing things like adding assertions into your real API to check that the real API works the way you expected it to, with the error messages pointing out where your understanding is not in tune with reality. I'll certainly be checking out your book, though I don't think you mentioned it during the presentation.
some prior art: Ed Jung (tech reviewer for our book) on mocking + patching pitfalls from pycon last year: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Ldlz4V-UCFw.html Yeray Diaz on dependency injection: "import as an antipattern" ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-qkGxy4c64Jg.html Brandon Rhodes: "hoist your I/O" which is actually a radically different way of doing it, but it has the same objective of decoupling infra from business logic: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-PBQN62oUnN8.html
