Question

I learned basics of web-based integration testing using SpecFlow and WatiN. From what I understand, SpecFlow decides whether test has passed based on whether a specific HTML markup is present on the page – buttons, links, etc.
But doesn’t that mean that my integration tests are tightly coupled to my UI? For example, if in feature ABC Watin looks for a specific HTML element to be present (let’s say it’s a table), and I suddenly change my UI so that this table becomes a bunch of divs, WatiN won’t be able to find it and my test for feature ABC will fail. How can I avoid such situations?
My suggestions are –
a) I should write WatiN tests so that they are minimally affected by changes to UI design
b) I should make UI design so that WatiN still understands it if I change it
c) I should use some library with WatiN that is able to recognize UI design changes
Any suggestions? Where am I wrong?
EDIT
I’m an idiot – I forgot to mention I’m using ASP.NET MVC

Answer 1

First you should decide if you really need to go through the UI. Probably and especially if you want to convince a stakeholder that these specs actually are exercising the system. But later on you might want to hit the system on the domain layer or right under the UI (the controller in a MVC architecture for example).

You might even want to be able to switch between the two versions

Either way you want to abstract away from having a tight coupling between your step definitions and the actual application (be it the page or the controller).

One way to accomplish this is to use the Page object pattern which basically is an wrapper class for the page you’re testing. This class gives you a nice interface to interact with the page (for example a method for submitting a form, properties for fill out the form and other properties to query the page for content).

How you actually interact with, or automate, the page is “hidden” within the page object and only need to change this one place if (when?:)) it changes.

This is not perfect of course, you still have a “tight” coupling to the page, but is now abstracted away in a separate class and that is at least a little better.

A tip is to try to keep you step definitions short. Super short – a single statement or row. And the move the rest of the logic down into an automation layer.

Also don’t miss this great presentation by Matt Wynne that shows this in great effect.