Semaphore

I am pretty skeptical about writing automated tests that interact with
the application under test at the user interface level. These UI tests
tend to be:

Slow in execution, since they are typically end-to-end tests from an
application-layer perspective, and

Demanding when it comes to maintenance, because the user interface is
typically a part of an application subject to frequent changes.

However, the user interface is often an important component of an
application, and therefore it requires testing effort. I’d like to talk
about a different approach to user interface test automation in this
blog post.

But first, let me explain a subtle yet important difference. On
one hand, there’s testing the user interface. Here, the actual
logic incorporated in the user interface is isolated and tested as a
unit. Everything that’s happening "behind" the user interface is out
of scope of the test and therefore usually mocked. On the other hand,
there’s testing application logic through the user interface. This is
generally done using tools such as Selenium. This type of automated
tests uses the user interface as its point of entry and validation,
even though the actual logic that processes the input and generates
the output to be checked is not implemented at the user interface
layer at all.

Now, only when you specifically want to perform end-to-end application
tests, or when there really isn’t any other option than to use the user
interface drive tests that validate underlying application logic should
you resort to tools such as Selenium. In all other cases, it might be a
better idea to see if there’s a better option available.

User Interface Architectures and Testability

In the remainder of this post I want to zoom in on a commonly used user
interface pattern, namely Model-View-ViewModel, or MVVM in short, and what
I think is a suitable approach for writing automated tests for user
interfaces adhering to this pattern.

MVVM Briefly Explained

The MVVM pattern lets you separate presentation logic (that defines what
information is shown on the screen) from the actual presentation (that
defines how the information is displayed). Schematically, the pattern
looks like this:

The View is the user interface, which is made up of textboxes, labels,
buttons, etc. It is responsible for defining the structure, layout and
appearance of what you see on the screen. The Model is an implementation
of the domain model. It consists of a data model along with business
rules and validation logic. The View Model is the intermediary between
the View and the Model, handling user interface actions (such as the
click of a button) and interacting with models usually by invoking
methods in the model classes (for example to update a record in a
database). It is also responsible for presenting data from the model
(for example the results of a query) to the view in a representation
that can be easily displayed on screen.

One of the key ideas behind MVVM and other user interface architectures,
such as Model-View-Controller (MVC) and Model-View-Presenter (MVP), is
that the separation of concerns ingrained in these architectures makes
them testable using unit tests, instead of having to rely on expensive
and slow end-to-end tests.

Testing User Interfaces Built on MVVM

Since all business logic is contained in the view model, it makes sense
to make it the center of attention for our testing efforts. Since view
models are implemented as classes in object orientedn languages these
tests are usually defined as unit tests. This immediately shows the value
of asking yourself: " Am I testing the user interface or merely testing
my application through the user interface?". In case of the former,
writing complicated, slow and brittle end-to-end tests with tools such
as Selenium is pure overkill.

Instead, we write a simple unit test that covers the business logic in
the view model. We mock the model part, since business and implementation
logic further down the application stack can be tested using (again) unit
tests, or when the view model for example invokes web services for storing,
processing and retrieving data, we can write API-level tests to cover that
part of our application. The view part can — when MVVM is applied correctly
— be left out of scope, since buttons, labels and text boxes are usually
standardized objects that ‘only’ need to be positioned correctly on
screen (in reality, designing good user interfaces is a respectable and
skillful job of its own, no disrespect intended). If you really want to
write checks to verify that the view part is implemented correctly,
there’s always tools such as Galen Framework
that allow you to check your user interface at the design level (i.e. visual checks).

Links to Example Implementations and Tests

Rather than writing my own example here, I’d like to link to some well-written
and understandable examples of the application of MVVM and the way you can
write unit tests for your MVVM-based user interface here. I’m currently in
the early stages of implementing a suitable testing approach for the user
interface of the key application at my current project, so you can expect
some real-life examples from my own hand in a future post. For now, I
encourage you to take a look at the following blog posts and examples: