What practices are used to avoid constantly testing the login screen in web driver tests?

Question

Good tests shouldn't shouldn't have duplication and should be concise, however when testing a web application with authentication the test must first get past authentication to perform the desired function.

With many tests this quickly means that the login screen (or equivalent) will be tested numerous times. I would ideally like to avoid this repetition.

One method is to create cookies and sessions to "trick" the browser into thinking the state for the test exists. This method quickly becomes complex with potentially many sessions needing to be created, and also increases the overhead of the test, especially if these need to be combined with database states.

Does anyone have a good solution for a complex applications, or a good pattern for managing multiple sessions, databases, and cookies if this is how they work?

Answer 1

If I understand correctly, you are looking at ways to make your tests more efficient, so you can get as quickly as possible to the desired state and then perform the actual assertion that the test case is intended to cover. There are a couple of options you have:

1. Use a class setup method, or application setup method to log in, then re-use your existing, open web browser to execute each test case. You may also need a corresponding cleanup method to execute at the end of each test to get you to a known state for the start of your test case. Most test runners support this, you would need to refer to the documentation of your particular test runner to get syntax.
2. Incorporate an http library to bypass the UI and send an HTTP request to log in, then set the session cookie value with webdriver's addCookie method so when you navigate to a specific page within your app, you will already be logged in. If you have other crud operations within your app, you can also have non UI versions of those actions as well. I have used this approach for creating new users, creating any kind of user specific content, etc, and have used it in my cleanup methods to delete content at the end of each test case, or test class. This saves time, and is usually more reliable than going through the UI. This is very useful when you have a test case where you want to assert on some behavior on a page showing details about some user created object (let's say an event in a calendar) and that event can have lots of different properties. Since you already have a test to create the calendar event through the UI, you don't need to do it over and over again for all of the tests that require an existing one, so you can send an http request to create the calendar event, then navigate to the page to view the event and execute your test assertion using the UI.

Answer 2

What I understood from your question. The main concern of yours is to avoid running login process during each test and to avoid this repetition.

I have simple solution for this problem. In your Base Class`, use the following code in "@BeforeClass" (To get cookies) and "@AfterClass" (to store cookies);

public class BaseClass {

    --------------------------- 
    --------------------------- 
    --------------------------- 
    --------------------------- 


    Set<Cookie> cookies;

    @BeforeClass
    public void setup()
    {       

        try
           {
             for(Cookie cookie:cookies)
          {
        driver.manage().addCookie(cookie);
         }
           }
        catch(Throwable e)
           {
        System.err.println("Error While setting Cookies: "+ e.getMessage());
           }

    --------------------------- 
    --------------------------- 
    --------------------------- 
    --------------------------- }


    @AfterClass
    public void tearDown()
    {       

    try
        {
        cookies=driver.manage().getCookies();
        }
        catch(Throwable e)
        {
        System.err.println("Error While getting Cookies:" + e.getMessage());
        }

    driver.quit()   
    --------------------------- 
    --------------------------- 
    --------------------------- 
    --------------------------- }}

Now use the following code into the other test cases by which you can bypass the login steps again and again to avoid repetitions.

@Test
public test1(){

driver.navigate().to("yoururlhere");
-------------------
-------------------
}

This will get login sessions from cookies without repeating login steps.

Answer 3

PageObject design pattern

Every test needs to log in, but code is in one place, and any test will just use it, just 1 line of code. Login is not a problem. Other stuff, to prepare application's data to certain state might be bigger waste of time (but again, can be wrapped as single pageobject call).

If you log just once, then run long trail of tests, they are dependent on the order. Dependency might be a good thing (one test prepares data for next) or not (weak link in the chain and more fragile tests), but you need at least to be aware of it.

Also if you use some trick which bypasses login as user would do it, are you testing your application as user would, or some other configuration? You are opening yourself to to heisenbugs which happen for user and not for your tests.