Facade Test by Mark Seemann
This post proposes the term Facade Test for an automated test which is more than a unit test, but not quite an integration test.
There are several definitions of what a unit test is, but the one that I personally prefer goes something like this:
A unit test is an automated test that tests a unit in isolation.
This is still a rather loose definition. What's a unit? What's does isolation mean? The answers to these questions seem to be a bit fluffy, but I think it's safe to say that a unit isn't bigger than a class. It's not a library (or 'assembly' in .NET terms). It's not all types in a namespace. In my opinion, a unit is a method... and a bit more. In OO, a method is coupled to it's defining class, which is the reason why I think of a unit as a bit more than a method.
If that's a unit, then isolation means that you should be able to test the unit without using or relying on any other moving pieces of production code.
Often, unit testing means that you have to decouple objects in order to achieve isolation. There's a few ways to do that, but Dependency Injection is a very common approach. That often leads to heavy use of dynamic mocks and too many interfaces that exist exclusively to support unit testing.
Sometimes, a good alternative is to write automated tests that exercise a larger group of classes. When all the collaborating classes are deterministic and implemented within the same library, this can be an effective approach. Krzysztof Koźmic describes that
Another example is AutoFixture, which has hundreds of automated tests against the Fixture class.
We need a name for tests like these. While we could call them Integration Tests, this label would lump them together with tests that exercise several libraries at once.
To distinguish such tests from Unit Tests on the one side, and Integration Tests on the other side, I suggest the name Facade Test
The reason why I suggest the term Facade Test is that such automated tests tend to mostly target a small subset of classes that act as Facades over many other classes in a library.
Comments
Unit test: usually just one class but occasionally a couple of closely related classes, constructed and executed directly from the test code. Runs fast and no contact with the outside world.
Database or Comms test: testing in isolation that a single class that interacts with something externally works. e.g. a class that accesses the database actually accesses the database, a class that contacts a remote server actual contacts a remote server (probably a special one we wrote for testing purposes).
Scenario test: multiple classes, but with all external dependencies replaced with test doubles (e.g. no database access, no SOAP calls, no HTTP requests). Object graph is constructed via the same mechanism as the real object graph. So in some sense this tests the DI configuration. This is a form of integration test, but everything runs in memory so they are quick. Most of our tests are at this level.
Acceptance test: full application running and tested with Selenium.
And then there is manual testing.
"Let's drive this through Facade Tests" now means something else than "Let's drive this through Unit Tests".