What is the correct way writing e2e tests?

Question

I have a task do create e2e for a web app, but I don't know what is the correct way doing it.

For example: In app there is a possibility to add new employee, so the scenario is as described:

1. Login to application(it can be implemented in TestNG @BeforeClass annotation)
2. Switch to correct role that have posibility to add employee
3. Forward to form & Filling form and submit
4. Switch to employee tab, assert that employee exists @AfterClass teardown

In testing project I have to use Selenium with TestNG.

My question is what is the correct way to do this? There are three possible options:

Option 1:

public class CreateEmployeeTest {


    @BeforeClass
    public void loginToApplication() {

        driver.get("url");
        new LoginPage(driver).login("username", "password");
    }

    @Test
    public void addNewEmployee() {
        new DashboardPage(driver)
                .clickAddEmployeeButton();

        new AddEmployeeForm(driver)
                .fillFirstName("Name")
                .fillLastName("LastName")
                .fillEmail("email")
                .submitForm();

        new WebDriverWait(driver, 10)
                .until(ExpectedConditions.urlContains("/employees"));
        assertThat(new EmployeeDetails(driver).getEmployeeName(), equalTo(String.format("%s %s", "Name", "LastName")));
    }

    @Test(dependsOnMethods = "addNewEmployee")
    public void verifyThatEmployeeIsOnList() throws InterruptedException {
         new DashboardPage
                .switchToEmployesTab()
                .search(String.format("%s %s", "Name", "LastName"));

        Assert.assertTrue(DashboardPage.checkThatUserIsOnList(String.format("%s %s", "Name", "LastName")));
    }
}

Is it correct to create tests like this? I mean to create few @Test in one scenario with 'dependsOnMethod' option.

Option 2:

public class CreateEmployeeTest {


    @BeforeClass
    public void loginToApplication() {

        driver.get("url");
        new LoginPage(driver).login("username", "password");
    }

    @Test
    public void addNewEmployee() {
        new DashboardPage(driver)
                .clickAddEmployeeButton();

        new AddEmployeeForm(driver)
                .fillFirstName("Name")
                .fillLastName("LastName")
                .fillEmail("email")
                .submitForm();

        new WebDriverWait(driver, 10)
                .until(ExpectedConditions.urlContains("/employees"));
        assertThat(new EmployeeDetails(driver).getEmployeeName(), equalTo(String.format("%s %s", "Name", "LastName")));

        new DashboardPage
               .switchToEmployesTab()
               .search(String.format("%s %s", "Name", "LastName"));

        Assert.assertTrue(DashboardPage.checkThatUserIsOnList(String.format("%s %s", "Name", "LastName")));

   }
} 

Option 2 Create one @Test and write a full scenario in it. If option two is correct - what is the best way with dealing with very long tests?

Option 3: Maybe two of examples are incorrect - your idea?

Answer 1

Your tests have a lot of page specific details in the test, the waiting, checking urls could be moved to the pageObjects. The action is adding an employee, not filling the form.

@Test
public void addNewEmployee() {
    // Arrange
    var dashboard = new LoginPage(driver).Login(user); // returns page with navigation
    var eManager = dashboard.navigateToEmployeeManagement(); // returns page employee formpage
    var employee = new Employee("Name", "LastName", "email"); // Simple data object

    // Act
    eManager.addEmployee(employee);

    // Assert
    Assert.True(eManager.employeeIsOnList(employee));
}

The test is easy to read, the complexity and abstractions are hidden in the pageObjects. As the addEmployee() method now contains your AddEmployeeForm and wait steps.

Answer 2

You can start with few things that i consider part of best practices rules:

1. driver should not be mentioned in a test class -> for this you can create a page object manager that creates the page objects you need
2. you can use the Fluent / Chain of invocation pattern for writing the TDD way
3. don't add too much details in the tests > keep them simple > all the logic should be in the page objects and the test should define the business flow

How your test could/should look:

private LoginPage loginPage;

@BeforeMethod
public void setLoginPage() {
    POM pom = new PageObjectManager(); /** gets pages with driver set */
    pom.getLoginPage();
}

@Test
public void test() {

    someObject = loginPage /** some object based on your app logic */
            .iLoginWith(methodThatGetCredentialsForSpecificUserLikeAdmin)
            .iAddEmployee(methodThatGeneratesDinamicEmployee); /** opens the form, fills and submits */

    Assert.assertTrue(someObject.theEmployeeIsOnList());
}