How do I write tests using Watin & SpecFlow that are not tightly coupled with your HTML markup?
I learned the basics of web integration testing using SpecFlow and WatiN. From what I understand, SpecFlow decides if the test passed based on whether specific HTML markup is present on the page - buttons, links, etc.
But doesn't that mean that my integration tests are tightly coupled with my user interface? For example, if in the ABC function Watin is looking for a certain HTML element that must be present (say, it is a table) and I suddenly change my interface so that the table becomes a bunch of divs, WatiN cannot find it and my ABC function test 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 in the interface design.
b) I have to create a UI design so that WatiN still understands it if I change it
c) I should use some library with WatiN capable of recognizing UI design changes
Any suggestions? Where am I wrong?
EDIT
I'm an idiot - I forgot to mention I'm using ASP.NET MVC
source to share
You must first decide if you really need to go through the interface. Perhaps, and especially, if you want to convince a stakeholder that these specifications actually enforce the system. But later on, you might want to get into the system at the domain level, or right below the UI (like in MVC architecture).
You may even want to switch between the two versions
Either way, you want to abstract away the tight coupling between step definitions and the actual application (be it a page or a controller).
One way to achieve this is to use the page object pattern , which is basically a wrapper class for the page under test. This class gives you a nice interface to interact with the page (for example, a form submission method, properties for filling out a form, and other properties for requesting a page for content).
How you actually interact or automate the page is "hidden" inside the page object, and only needs to change this place if (when? :)) it changes.
This is not ideal, of course you still have a "tight" link to the page, but now it is separated in a separate class and that is at least a little better.
The council should try to summarize the definitions of the step. Super short is one statement or line. And move the rest of the logic to the automation layer.
Also don't miss this great presentation from Matt Wynn, which shows it with great effect.
source to share