PageObject pattern, FluentAPI and method chaining

23 April 2013

You will find the PageObject pattern here.

I find this level of abstraction very important when you’re writing automation tests. Regardless of your test approach I have found that having a Fluent API that is documented helps other developers understand the flow of the intended application. The fluent API will encapsulate control lookups and interaction. This gets easier if you have applied a convention to your UI layouts and control styles.


The example below is quite rudimentary.

/// <summary>
/// Ensure that the logout button 'works'
/// Also checks that the user is on work by default.
/// </summary>
public void LogoutButtonWorks()
        .IsLoginPageLoaded((loaded) => { Assert.IsTrue(loaded, "Login page wasn't loaded"); })
        .IsLoginPageLoaded((loaded) => { Assert.IsTrue(loaded, "Login Page Expected"); });

Debugging is a pain

When something goes wrong in the Fluent API debugging can be a pain. Some debuggers will not be able to set a breakpoint within the chain.

Add Logging

Add logging to your methods so you can see where your application got up to. You can also apply logging using interceptors should you be using an IoC Framework such as Spring or NInject (Many more available).