Methods — reusable steps

as a manual tester

Your test cases say 'Precondition: user is logged in' instead of re-writing login steps in all 40 cases.

→

in automation

A method is exactly that: name the steps once, reuse them everywhere. login() is your precondition, as code.

A method is a named, reusable block of code. It can take parameters (inputs) and return a value (output). This is the single most important structuring tool you'll use — the Page Object Model in Suite 04 is really just methods organized well.

anatomy of a method

//  returns   name        parameters
//    ↓        ↓              ↓
static boolean isValidEmail(String email) {
    return email.contains("@") && email.contains(".");
}

// using it ("calling" it):
boolean ok = isValidEmail("qa.tester@example.com");  // true

Why testers should care deeply

Imagine login steps copy-pasted into 40 test scripts. The login page changes. You now fix 40 files — this is how automation suites die. With a login(username, password) method, you fix one place. Duplication is the disease; methods are the cure.

LoginSteps.java — test steps as methods

static void login(String username, String password) {
    System.out.println("Navigating to login page");
    System.out.println("Typing username: " + username);
    System.out.println("Typing password: ****");
    System.out.println("Clicking Sign in");
}

static String getBannerText() {
    return "Welcome back!";   // later: read from the real page
}

// a test becomes short and readable:
login("qa.tester", "S3cure!Pass");
if (getBannerText().equals("Welcome back!")) {
    System.out.println("PASS");
}

predict: what does this print? think it through, then reveal

output

Navigating to login page
Typing username: qa.tester
Typing password: ****
Clicking Sign in
PASS

Notice the shape: void methods do things (actions), returning methods fetch things (state to assert on). Good test code keeps that separation — it'll become the backbone of your page objects.

About static: for now it just means "callable without creating an object." It disappears naturally once you learn classes in the OOP lesson — don't overthink it yet.

⚡ exercise · design a checkout step library

Without writing full bodies, declare method signatures (return type, name, parameters) for reusable steps of an e-commerce checkout test:

Add a product to the cart by product name
Get the current cart total
Apply a discount code
Check whether the checkout button is enabled

show a solution

static void    addToCart(String productName)
static double  getCartTotal()
static void    applyDiscount(String code)
static boolean isCheckoutEnabled()

Actions return void; questions return a value. That instinct is page-object design already.

references

Oracle Java Tutorials — defining methods

key takeaways

Methods name a set of steps once and reuse them everywhere.
Parameters make steps flexible; return values hand back state for assertions.
Actions return void, questions return values — keep the separation.
Killing duplication is what keeps automation suites maintainable.