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.
However, there are
still problems with this approach. Two
of the biggest problems are
- changes to the layout template break all tests
- inability to test JavaScript manipulations of the page.
