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

	class B
	{
	A a = new A();
	public F()
	{
	return a.G(...);
	}
	}
	// Test:
	result = new B().F();

view raw TestingAThroughB.cs hosted with ❤ by GitHub

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

	class A
	{
	ctor(B b)
	{
	this.b = b;
	}
	public F()
	{
	// Something that doesn't use B
	}
	}
	// Test:
	result = new A().F();

view raw TestAButBIsAlongForTheRide.cs hosted with ❤ by GitHub

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.

	// Tests for A
	result = new A(fakeB).F();
	// Tests for B
	result = new B().G();
	// Tests that they work together
	subject = new A(new B());
	result = subject.F();

view raw TestThatAAndBWorkTogether.cs hosted with ❤ by GitHub

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.