And when I look at the kinds of tests they're talking about, I see a bunch of different things. Each of these things is worth considering separately, but we lack crisp terminology for them. (I've touched on this before.)
1. Testing class A through B
Loading Gist cc384ef8739df7f39ca7...
2. Testing class A, but B is incidentally along for the ride
Loading Gist a816a0e33d2e6fc2b593...
3. I have tested classes A and B separately, but now I want to test that they work together.
That is, that they integrate correctly.
Loading Gist 6581d5b326653cdd8b52...
4. My business logic is testable in isolation, but then I have an adapter for each external system; I test these adapters against the real external system. I call this a focused integration test, and it happens when I use Ports/Adapters/Simulators.
5. I have unit tested bits of my system to some degree, but I don't have confidence that it's ready to ship until I run it in a real(ish) environment with real(ish) load.
6. I am responsible for one service; you are responsible for another; our customers only care that they work together. We deploy our services to an integration environment, and run end-to-end tests there.
1 comment:
I have one bit of "crisp terminology": I don't use integrated tests to check the basic correctness of code over which I have control. I only run integrated tests to check my integration with third-party stuff, and I relentlessly squeeze the surface of integration to become smaller over time.
Post a Comment