Acceptance Testing need not use the Full Stack

Solution

Benefits

The key point was the use of contract testing. Without contract testing, writing automated acceptance tests is a pretty awful process.

Data requires setup and tear down. Any data changes can break your tests and the UI is often in flux.

By substituting the UI layer, or the DB access with fakes such as a console view, or in memory hash table, your tests can still cover the whole stack, but in a more stable, bite size manner. You simply test your real view or data access separately to prove they work, and can in fact be swapped out thanks to the Liskov Substitution Principle (LSP) by running the same suite of tests against your fakes!

I'll be expanding on how and what contract testing is in a future post.