We often get scenarios, where the same action on a particular page object could potentially lead a user to more than one valid page objects. This could be as a result of change in the environment tests are being ran, but more commonly as a result of the data being passed in. For example, when an admin logs into a site, he should be directed to the admin dashboard. When a customer logins using the same login form, he should be directed to customers’ page. The actions and steps involved are exactly the same. However, the outcomes are different as a result of the input.


  • Actions that could lead to different Page Objects
  • Developing the Login Page

Pre-requisite/ Tools:

  • Previous Posts
  • Intermediate to advance C# knowledge/ OOP concept (classes, Methods, Properties)
  • The Application Under Test on Instant WordPress

Let’s explain further using our Application under Test.

Start Instant WordPress

Click Login from the Side Meta Page Object from our previous model of the home page.

This should take you to the login page. The correct details are, username = admin, password = password

Lets look at some potential test cases:

Test case Expected result
Leave password empty and click login ERROR: The password field is empty.
Leave username empty and click login ERROR: The username field is empty.
Input incorrect password and click login ERROR: The password you entered for the username admin is incorrect. Lost your password?
Input incorrect username and click login ERROR: Invalid username. Lost your password?
Leave both fields empty No errors.
Input correct username and password then click login User is directed to Dashboard

Depending on the test being carried out, we have to cater for these scenarios. From the above test cases, I can say there are a minimum of 3 possible page objects a user who tries to login could end up as depicted in the diagram below.


Developing the Login Page Functions

Remember, we want the click action to return other page objects, for easy scripting and so we can chain our method calls. The solution to this is very simple. We will make separate public methods to cater for these scenarios. There more complex ways to deal with this, but I like simple. For now, anyway.

This part we will consider 4 pages represented by classes to start with. A good practice is to only capture the page object elements that you need at a particular time. For example, the ‘Side Meta Page Object’ has about 4 links, but we are not going to worry about the rest of them for now. Only the Login link we will try to locate.

Page Objects Class Name Notes Functions
Side Meta Page Object SideMetaPObject.cs Multiple links  Access to login page
Wp Login Page Object WpLoginPObject.cs Empty details returns same page with no errors User Authentication

Language selection

Password storage

Access to Password retrieval

Access back to homepage

Login Error Page Object LoginErrorPObject.cs Not visible on page load

Same locator for different error types only displayed data is different.

Access to Password retrieval page in specific condition, e.g. both username and password are wrong.

Access to Password retrieval page
Dash Board Header Page DashBoardHeaderPObject.cs Display Username

Change language


Let’s open of our previous solution and do some coding.


  1. The first thing is to create our classes and name them accordingly
  2.  Then we will start with the Side Meta Page Object and declare a single property which we will use to locate the login link using partial link text.
  3. We declare a single method that simply navigates to the login page. This method returns the login page object, with the elements contained initialized.
  1. In the WP Login Page Object, we declare 3 properties for the relevant elements which we locate them using Ids
  2. We have at least 4 public methods that will perform various Login function test scenarios.
  3. These methods return their relevant Page objects which will be determine by the type of tests being carried out. This is usually driven by the type of data the person writing the scripts will pass in.
  4. The fourth private method fills in the username and password passed in from the script, and clicks login.

For the error page object,

  1. Type in incorrect credentials to bring up this page
  2. We declare a single property and locate the error section by id.
  3. We have one single method that returns a string which will be the text property of the error section. Note, inputting both credential wrong includes a link for password reset, but we will leave that for now.

For the Dashboard,

  1. Nothing fancy, we will login with correct credentials and declare a property to represent the displayed username located using css selector.
  2. We will also have a method to get the displayed details of user.

Finally, we will modify the TatWeb.cs class and add the property to access the Side Meta Page.

public static SideMetaPObject SideMetaPage
       return DoInitialize.PageElementsIn<SideMetaPObject>();


  1. In Our .Test project, create a new test class called LoginTests.cs extending the TestBase class;
  2. Declare 3 methods as shown to cover the different scenarios.
  3. As usual, we start our tests with TatWeb and as soon as we type the period, we can see that intellisense gives us the option of the SideMetaPage page object.

  1. In the incorrect details test, we have leverage the NUnit attribute ‘TestCase’ to parameterize our test cases. The first string for the username, second for the password, and the third expected result.

Ensure the AUT is running, and run the tests.


We have been able to provide a way to script against the login form. We have taken into consideration different scenarios, as clicking the login button does not always lead to the same outcome. Rather, it depends on the input.

With This approach, we can see a lot of test cases can be scripted very quickly. Imagine an input box within a form on a web page that requires minimum and maximum characters. Instead of choosing random input, testers can employ testing techniques e.g. Boundary value analysis, equivalence partitioning etc. to effectively and quickly find bug. The same public methods exposed from the framework, should be able to handle all these test inputs without any modification to the framework code. In fact as we have seen, the actual script code could be reused with parameterization.

Our Framework is growing, before it gets too big, it is a good practice to do the documentation as we move along. We will briefly switch focus to more framework development, and put in place tools to aid with documentation in the next post.

Subscribe below and be the first to be notified when this is published.

Any thoughts, questions, comments, addition, or anything you don’t like, do not hesitate to leave a comment or contact me. Thank you!

Completed Files:

Click Here to Download the Complete Working Solution.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons