On Thu, Aug 29, 2019 at 1:46 PM Aryeh Gregor <a...@aryeh.name> wrote:
> On Thu, Aug 29, 2019 at 1:02 AM Krinkle <krinklem...@gmail.com> wrote: > > What did you want to assert in this test? > > In a proper unit test, I want to completely replace all non-value > classes with mocks, so that they don't call the actual class' code. > This way I can test the class under test without making assumptions > about other classes' behavior. > > Using createMock() for an interface or class makes sense to me mostly for external dummies that are requires for some reason (an anti-pattern that I think should be avoided. If such a dependency is truly optional and of the fire-and-forget type, it should have a no-op implementation that is used by default, like we do with Loggers. For anything else, it doesn't really work in my experience because PHPUnit won't actually provide a valid implementation of the interface. It returns null for anything, which is usually not a valid implementation of the contract the class under test depends on. As a result, you end up with hundreds of lines of phpunit-mockery to basically reimplement the dependency's general functionality from scratch, every time. I have seen this too many times and fail to see the added value for all that complexity and maintenance, compared to simply letting the actual class do its work. Practically speaking, what kind of problem would that test methodology catch? I believe others may have a valid answer to this, but I haven't yet seen it. Perhaps it's a source of problems I tend to prevent by other means. There's more than one way to catch most problems :) You can draw from that that my definition of "unit" and "integration" are probably different from yours. To me a unit is a single class, but I think it's fine to be given other class objects. I see each unit an isolated subtree, a controlled environment where all dependencies are known, explicitly specified, injected, and have no side-effects after the test is done apart from within the objects you created for that test. -- Timo _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
