Sunday, December 6, 2015

Types of integration/integrated test

I've noticed that people often use these terms interchangeably.

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

2. Testing class A, but B is incidentally along for the ride

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.

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:

J. B. Rainsberger said...

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.