Web UI Testing Part 1: Front-door and back-door testing

Llewellyn Falco and I had a conversation many years ago (June 2010?) about the best way to test Web UI.  During that conversation we referred to the two classifications/mechanisms of web testing as front-door and back-door web testing.  That is how I still think of the two types many years later, although I recognize that not many people in the industry use those terms. 

In front-door web testing you are using the browser to drive the test, which more closely tests what the user sees, but offers limited ability to manipulate or control the data and other dependencies.  The other drawback of this type of testing is if the test modifies data, there needs to be some way to get back to a clean slate after the test finishes.

In back-door web testing you call the controller or presenter directly (assumes you are using MVC pattern, or have done a good job separating the Greedy view into a presenter).  The advantage of this pattern is that you can control the dependencies and data context under which the test runs more easily by using in memory repositories, mocks, and things of that nature.  The main issue with this type of testing is that these controller methods return some sort of model and view name, making it difficult to test what the user sees.  Because of this, you can have complete test coverage over the controllers but still have bugs in the view.

In January of 2011 ASP.NET MVC 3 was released which allowed different view engines to be used to render the views into HTML that would be sent back to the client.  Because the View engines were easily pluggable and the Razor Engine was packaged separately (https://www.nuget.org/packages/RazorEngine/) this allowed back door testing to call the engine to produce HTML.  This allowed back-door web testing to get closer to what the user was seeing and eventually resulted in Llewellyn augmenting Approval tests with a mechanism for approving HTML.

http://blog.approvaltests.com/2012/05/testing-views-in-aspmvc.html

However, there are still problems with this approach.  Two of the biggest problems are

1. changes to the layout template break all tests
2. inability to test JavaScript manipulations of the page.