This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Message originally sent by slack user U71OMUUQZNW
hi all! as we continue to use packs more at FireHydrant, we were discussing testing and boundaries. we’ve kinda been going with the idea that pack tests shouldn’t reach into other packs, so we mostly ensure that the pack’s public interface was called as expected. then within the pack, we test that if the public interface is called as expected, everything on the pack side works as expected. however, you still have that gap that traditional contract testing is meant to solve: ensuring that your expected usages match and are compatible.
how are y’all handling the integration testing side of this problem?
If you want to keep going down this route, then you’ll have to end up in a place similar to what APIs do that ship libraries for their consumption and in those libraries they ship a test harness so that you can test the API without invoking it.
This ensures that the control of the test harness (~==contract) is with the owner of the API.
I haven’t found a good way of doing this with packs yet and haven’t seen proposals.
Message originally sent by slack user U71OMUUQZNW
that sounds about the direction we’re headed, thanks for the response. as we continue to feel out what this test harness looks like, I’ll try to report back here with what we learn!
Message originally sent by slack user U712YWCKK8T
In my experience, and the wisdom at Google when I used to work there, doing this essentially ends up meaning you implement everything twice, and ensuring the fake implementation always matches the real implementation is impossible. The recommendation there that I still follow is to avoid stubs and mocks unless they are absolutely necessary, and instead create matchers/test helpers that make it easier to check the full behaviour was correct.
Message originally sent by slack user U712YWCKK8T
It’s the “unit tests passed, integration tests fail” meme