Why organization scales test suites in JUnit - Automation Benefits in Action

Verify that the login functionality works correctly for multiple users

Preconditions (2)

Step 1: Open the login page

Step 2: Enter username 'user1' and password 'Password1!'

Step 3: Click the login button

Step 4: Verify that the user is redirected to the dashboard page

Step 5: Logout

Step 6: Repeat steps 2-5 for 'user2' with password 'Password2!'

Step 7: Repeat steps 2-5 for 'user3' with password 'Password3!'

✅ Expected Result: Each user should be able to login successfully and reach the dashboard page without errors

Automation Requirements - JUnit 5

Assertions Needed:

Verify current URL is dashboard URL after login

Verify login button is clickable

Verify logout button is present after login

Best Practices:

Use parameterized tests to run the same test with multiple user credentials

Use explicit waits if needed for page load

Keep test methods small and focused

Use descriptive test method names

Automated Solution

JUnit

import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import java.time.Duration;

public class LoginTest {
    WebDriver driver;
    WebDriverWait wait;

    void setup() {
        driver = new ChromeDriver();
        wait = new WebDriverWait(driver, Duration.ofSeconds(10));
        driver.get("https://example.com/login");
    }

    void teardown() {
        if (driver != null) {
            driver.quit();
        }
    }

    @ParameterizedTest(name = "Login test for user: {0}")
    @CsvSource({
        "user1, Password1!",
        "user2, Password2!",
        "user3, Password3!"
    })
    void testLogin(String username, String password) {
        setup();
        try {
            WebElement usernameField = wait.until(ExpectedConditions.elementToBeClickable(By.id("username")));
            usernameField.clear();
            usernameField.sendKeys(username);

            WebElement passwordField = driver.findElement(By.id("password"));
            passwordField.clear();
            passwordField.sendKeys(password);

            WebElement loginButton = driver.findElement(By.id("loginButton"));
            assertTrue(loginButton.isEnabled(), "Login button should be enabled");
            loginButton.click();

            wait.until(ExpectedConditions.urlContains("/dashboard"));
            assertTrue(driver.getCurrentUrl().contains("/dashboard"), "URL should contain /dashboard after login");

            WebElement logoutButton = wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("logoutButton")));
            assertNotNull(logoutButton, "Logout button should be visible after login");

            logoutButton.click();
            wait.until(ExpectedConditions.urlContains("/login"));
        } finally {
            teardown();
        }
    }
}

This test uses JUnit 5 with parameterized tests to run the login test for multiple users.

The @CsvSource annotation provides three sets of username and password inputs.

In setup(), we open the browser and navigate to the login page.

We wait explicitly for the username field to be clickable before entering credentials.

We assert the login button is enabled before clicking it.

After login, we wait for the URL to contain '/dashboard' and assert it.

We verify the logout button is visible, then click it to logout and wait for the login page again.

Finally, teardown() closes the browser to clean up.

This approach scales well because adding more users only requires adding more lines in the @CsvSource. It avoids repeating code and keeps tests clear and maintainable.

Common Mistakes - 3 Pitfalls

Hardcoding user credentials inside the test method instead of using parameterized tests

Not using explicit waits and relying on Thread.sleep()

Not closing the browser after each test run

Bonus Challenge

Now add data-driven testing with 3 different invalid login inputs and verify error messages

Show Hint

Practice

1. Why do organizations scale their test suites in JUnit?

easy

A. To avoid running tests altogether

B. To make tests run slower and more detailed

C. To reduce the number of tests written

D. To keep tests fast and reliable as the project grows

Solution

1. Step 1: Understand the purpose of scaling test suites

   Scaling test suites helps maintain speed and reliability when many tests exist.

2. Step 2: Identify the benefit for organizations

   Fast and reliable tests help teams catch bugs early and save time.

3. Final Answer:

   To keep tests fast and reliable as the project grows -> Option D

4. Quick Check:

   Scaling test suites = keep tests fast and reliable [OK]

Hint: Scaling means keeping tests fast and reliable [OK]

Common Mistakes:

• Thinking scaling slows down tests
• Believing scaling reduces test count
• Assuming scaling skips tests

2. Which JUnit annotation is used to group tests into a suite for scaling?

easy

A. @Suite

B. @BeforeEach

C. @Test

D. @RunWith

Solution

1. Step 1: Identify the annotation for test suites

   @Suite is the annotation used to group multiple test classes into a suite.

2. Step 2: Differentiate from other annotations

   @Test marks individual tests, @BeforeEach runs setup, @RunWith changes runner behavior.

3. Final Answer:

   @Suite -> Option A

4. Quick Check:

   Group tests = @Suite [OK]

Hint: Use @Suite to group tests into suites [OK]

Common Mistakes:

• Confusing @Test with suite grouping
• Using @BeforeEach for grouping
• Mistaking @RunWith for suites

3. Given this JUnit 5 code snippet, what is the main benefit of running tests in parallel?

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.parallel.Execution;
import org.junit.jupiter.api.parallel.ExecutionMode;

@Execution(ExecutionMode.CONCURRENT)
class SampleTests {
    @Test
    void testA() throws InterruptedException {
        Thread.sleep(1000);
    }
    @Test
    void testB() throws InterruptedException {
        Thread.sleep(1000);
    }
}

medium

A. Tests run at the same time, reducing total time

B. Tests run one after another, increasing total time

C. Tests fail because of concurrency issues

D. Tests skip execution to save time

Solution

1. Step 1: Understand @Execution(ExecutionMode.CONCURRENT)

   This annotation runs tests in parallel, allowing simultaneous execution.

2. Step 2: Analyze the effect on test duration

   Both tests sleep 1 second but run together, so total time is about 1 second, not 2.

3. Final Answer:

   Tests run at the same time, reducing total time -> Option A

4. Quick Check:

   Parallel tests = faster total run [OK]

Hint: Parallel tests run together, saving time [OK]

Common Mistakes:

• Assuming tests run sequentially
• Thinking concurrency causes failures here
• Believing tests skip execution

4. Identify the error in this JUnit 5 test suite setup that prevents scaling:

import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses({TestA.class, TestB.class})
public class AllTests {
    @Test
    void dummy() {}
}

medium

A. @SelectClasses should list only one class

B. Missing @RunWith annotation for suite

C. The suite class should not have @Test methods

D. Test classes must be abstract

Solution

1. Step 1: Check suite class structure

   JUnit 5 suite classes should only group tests, not contain @Test methods themselves.

2. Step 2: Identify the problem

   Having a @Test method in the suite class breaks the suite's purpose and can cause confusion.

3. Final Answer:

   The suite class should not have @Test methods -> Option C

4. Quick Check:

   Suite class = no @Test methods [OK]

Hint: Suite classes group tests, don't add @Test methods [OK]

Common Mistakes:

• Adding @Test methods inside suite class
• Thinking @RunWith is needed in JUnit 5 suites
• Believing only one class can be selected

5. An organization wants to scale its JUnit test suites to run thousands of tests quickly and reliably. Which combination of strategies best achieves this goal?

hard

A. Write fewer tests, skip flaky tests, run all tests in one suite

B. Group tests into suites, run suites in parallel, isolate tests to avoid interference

C. Group tests into suites, run suites sequentially, avoid parallelism

D. Run tests randomly without grouping to save setup time

Solution

1. Step 1: Identify effective scaling strategies

   Grouping tests into suites organizes them logically and helps manage execution.

2. Step 2: Understand parallel execution and isolation

   Running suites in parallel speeds up testing. Isolating tests prevents interference and flaky failures.

3. Step 3: Evaluate options

   Group tests into suites, run suites in parallel, isolate tests to avoid interference combines grouping, parallelism, and isolation, which are best practices for scaling.

4. Final Answer:

   Group tests into suites, run suites in parallel, isolate tests to avoid interference -> Option B

5. Quick Check:

   Suites + parallel + isolation = best scaling [OK]

Hint: Combine suites, parallel runs, and isolation for scaling [OK]

Common Mistakes:

• Running suites only sequentially
• Skipping tests instead of organizing
• Ignoring test isolation causing flaky results