2 ms·
I’m generally not fond of e2e or even integration testing. At least, I prefer to keep them to a minimum, and use other tools to ensure units interact as expecte
by eyelidlessness 5y ago
I’m generally not fond of e2e or even integration testing. At least, I prefer to keep them to a minimum, and use other tools to ensure units interact as expected.
That said, where e2e tests may be valuable but costly as described in the article, it occurs to me that narrower integration tests which invert responsibility may be better. Which is to say:
- Given Service A
- Given Service B which depends on Service A
Integration tests of Service A may provide more value if implemented in Service B. It’s SB, after all, which understands the behavior it expects from SA. (If they’re mutual dependencies, of course the inverse applies as well.)
Of course, this highlights (at least for me) why integration tests should be limited in scope. If both services are well tested at the unit level, you will probably end up with a lot of redundancy between their reciprocal test suites. But at least at the idea level, this feels like a better compromise than expecting Team SA to anticipate all of the subtleties Team SB might have in mind.
- CobrastanJorji 5y agoWhat are the tools you do use to ensure units interact as expected?
- eyelidlessness 5y agoMostly making types more specific. Within a service, ensuring semantics are part of the type so they can be checked statically, and designing function boundaries so those semantics are part of the interface. Between services, using standardized machine-usable docs (like OpenAPI and JSONSchema) to share those types in a well-defined way. This is harder because network boundaries are less flexible, but it does help a lot.
- catern 5y agoYeah, I think the easiest way to test that Service A is meeting its API obligations is to send some requests to Service B. Hyrum's Law means that that's the only way to really test the important aspects of Service A's API. And I think this can be generalized into a general philosophy of using your users as a test suite for your API: http://catern.com/usertests.html http://catern.com/usertests.html