User Interface (UI) testing

While unit testing and integration tests usually focus on the back-end of your code, what your customer will still see is the user interface, or at least for most of our development that's it.

Therefore having tests on the interface is not useless while usually being quite hard to implement.

As I develop mainly web applications and therefore I will concentrate here on this particular kind of UI.

Depending how you developed your software, if it is a single page application (SPA) you could actually develop tests all in JavaScript. It's by far not as crazy as it seems, the issue is that you will need a full browser to run it, and you can't really fire it from a build server.

The other option is independent of how your page is developed and can (and will) run on a build server: WebDriver, Selenium & PhantomJS

If you are like me developing in .NET simply grab PhantomJS and Selenium.WebDriver having that let you have an headless Chrome, with all the binding to pilot it from your test functions.

Initializing the web driver is matter of:

DriverService = PhantomJSDriverService.CreateDefaultService();
DriverService.HideCommandPromptWindow = true;
DriverService.IgnoreSslErrors = true;
browser = new PhantomJSDriver(DriverService, new PhantomJSOptions());

Now that you have your "browser" you can issue your command like:

browser.Navigate().GoToUrl("http://myurl.com");

Finding an element on the page is done via:

browser.FindElement(By.Id(id))

With the IWebElement received you can check the content (.Text) or "click" it (.Click()) or type to it (.SendKeys("xxx"))

All that let you build your automated web UI tests, and finally check those interface to see that a change don't break everything down.

Don't be fooled however: it will be work to really test your UI, but I'm sure that once you have your UI covered with a good number of tests you will see how useful it is.

I did myself a smallish framework to help me writing those tests and at the end a test can be written like:

[TestMethod]
public void QuickSearch_LabelSearch()
{
    Url("/#action=ListBootPc");
    WaitElementStartsWith("contentArea", "Boot PC");
    WaitElement("quickSearch").SendKeys("CR12");
    WaitVisible("quickSearchResult");
    Assert.AreEqual(10, WaitElement("quickSearchResult").FindElements(By.TagName("a")).Count());
}

As you see it's really seen from .NET as a normal Unit Test and therefore can be understood by TFS and run like once a day.