How do you design Page Object Model without duplicates?

Question

I'm working on UI automating testing, using POM with Python and Selenium. I want to know how to handle duplicate test cases.

For example, you have two webpages: Login page and Homepage. I want to test three test cases.

1. Homepage functions without login: test_homepage_before_login.py
2. Login with valid/invalid username and password: test_login.py
3. Homepage functions with login: test_homepage_after_login.py

(1 and 3 have a lot in common. 3 has additional functions. 1 is subset of 3)

There are three files for each test case, and I already implemented 1 and 2. But for the third one, I just imported relevant functions from 1 and 2 modules.

The thing is validating login is duplicate. In this case, do you do login validation every time? Also do you give order or dependency when automating these cases by using pytest-ordering or pytest-dependency?

Another case I can think of is "logout". When you automate logout function, you need to log in first. In this case, do you add login validation beforehand again and implement logout? Do you give dependency in this case as well or just make scripts independent?

Thank you in advance.

Answer 1

You can use cookies to handle authentication. It will greatly speed up your tests. An example:

public void setAuthenticationCookies() {
        Cookie at = new Cookie("Cookie_AccessToken", prop.getAccessToken(), "/", DatatypeConverter.parseDateTime("2030-01-01T12:00:00Z").getTime());
        Cookie rt = new Cookie("Cookie_RefreshToken", prop.getRefreshToken(), "/", DatatypeConverter.parseDateTime("2030-01-01T12:00:00Z").getTime());
        driver.manage().addCookie(at);
        driver.manage().addCookie(rt);
}

For more: https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/Cookie.html

For logout issue, I advice you to login first then logout in order to make your tests independent of each other.

Answer 2

As this is a design question, there's no one right answer, but I'll give you some tips and guidelines that I follow.

• I don't design each test to correspond to a page. Instead, I design short scenarios that verify behaviors and outcomes that are most relevant to the customer
• Login is a very specific and special case. Usually most tests need to start with login in order to get to what they actually need to test, though they don't really care to verify the login process per se. In addition, you usually want to have some other tests that specifically verify the login process. For the first category of tests, you can perform the login either before each test and even before all the tests using a fixture. The fixture may verify that the login succeeded, just to prevent the test from continuing in case of a failure, but I don't consider it to be part of what the test validates. This fixture should perform the login in the simplest and most reliable way, because it's purpose is not find more bugs, but rather to help us get to where we really care about in the test. This means that you may use API or take any other shortcut in order to be in a logged in state.
• For the tests that are specific to login I'll often combine them with the registration process, as the main purpose of the registration is that it will allow the user to login, and the success of logging in is the result of the registration process, so there's no much purpose to test one without the other.
• Regarding reuse of code and page objects: following my first bullet, the process I follow is to write each test in a way that describes the scenario in the most readable fashion, using classes and methods that don't exists yet. Then I implement theses classes and methods to make the test pass. On the second test and on, if I realize that I already implemented an action, I reuse this code, and if I need something similar to something I already implemented, but not exactly the same, I refactor the original function to be usable in my new test, removing any duplication along the way. This help me design my code in a very reusable and duplication-free manner. Sometimes it leads me to create page objects, and other times it leads me to other design patterns. You can find a much more detailed explanation about this method including a step by step tutorial on my book Completed Guide to Test Automation.

HTH.