If you already are busy with high priority tasks like regression testing, you can be left wondering if it is a good use of time as sometimes, you have to read existing code for automated tests to figure out what is it they are supposed to achieve.

Common causes of confusion are:

• The names of methods, functions, and classes do not follow a clear naming convention and are not very informative about their purposes.

• There is little or no documentation in the form of documentation strings (docstrings) or comments that could provide definitions for functions and classes.

Why Documenting Your Code Matters

We've all been there – you inherit a test automation suite, and it feels like you're deciphering an ancient manuscript. Without proper documentation, understanding the purpose of each test case or the rationale behind a particular design choice can be akin to solving a complex puzzle.

Documentation isn't just a box to tick; it's the key to maintaining, scaling, and collaborating on our automation projects effectively. So, let's explore a few ways we can make our code speak volumes.

1. Clear and Concise Comments

Think of comments as post-it notes for your code. When you're knee-deep in scripts, a well-placed comment can be a lifesaver. Describe the purpose of a function, the expected inputs, and any important considerations. Trust me; your future self will thank you.

// Function to log in to the application
fn login(username: &str, password: &str) {
    // Entering username
    enter_text("username_field", username);

    // Entering password
    enter_text("password_field", password);

    // Clicking the login button
    click_button("login_button");
}

2. Documenting Test Cases Like a Story

Tests should read like a story, not a technical manual. Break down the steps in a logical order and use comments to provide context for each action.

#[test]
fn verify_successful_login() {
    // Step 1: Navigate to the login page
    navigate_to_login_page();

    // Step 2: Enter valid credentials
    enter_credentials("username", "password");

    // Step 3: Click the login button
    click_login_button();

    // Step 4: Verify successful login
    assert_element_visible("dashboard");
}

3. Inline Documentation for Complex Logic

When dealing with intricate logic, take the time to explain your thought process. A few extra lines of comments can save hours of head-scratching down the line.

// Applying a custom wait to handle dynamic elements
async fn custom_wait(element_locator: &str) {
    // Explanation of the wait strategy
    wait_until_element_visible(element_locator, TIMEOUT).await;
}

4. Update Documentation Alongside Code Changes

As we add features or refactor code, documentation should evolve with it. Nothing is more confusing than outdated comments. Treat documentation as a living, breathing part of your project.

In Conclusion

Investing time in meaningful code documentation isn't just a nicety; it's a necessity. It's the bridge that connects developers, making collaboration smoother and onboarding faster. So, the next time you're tempted to skip the comments or rush through documenting your test cases, remember that you're not just writing for today – you're writing for the future success of your project and your team.

For Extra Reading

1. Naming Convention — 9 Basic Rules for any Piece of Code | by Ran Greenberg | Wix Engineering | Medium

2. Quality Assurance Handbook | Automation / General / Naming convention (infinum.com)