Cyberdudebivash

top 10 java test automation scripts of all time

, , ,
CYBERDUDEBIVASH

Author: CyberDudeBivash
Powered by: CyberDudeBivash Brand | cyberdudebivash.com
Related:cyberbivash.blogspot.com

 Daily Threat Intel by CyberDudeBivash
Zero-days, exploit breakdowns, IOCs, detection rules & mitigation playbooks.

Follow on LinkedInApps & Security Tools

CyberDudeBivash Authority Edition

How to Automate JAVA / Selenium Test Cases & Integrate to an Automation Test Framework

A production-grade, enterprise-ready guide for QA, SDET, DevOps & DevSecOps teams.

Author: CyberDudeBivash  |  Powered by CyberDudeBivash

Official Ecosystem

cyberdudebivash.com
cyberbivash.blogspot.com
cryptobivash.code.blog
cyberdudebivash-news.blogspot.com

Affiliate Disclosure: Some links below are affiliate links. If you purchase through them, CyberDudeBivash may earn a commission at no extra cost to you. We recommend products/services based on relevance and practical value for QA, automation, DevOps and security teams.

Partner Picks (Recommended by CyberDudeBivash)

Edureka
Automation & QA CoursesKaspersky
Endpoint SecurityTurboVPN
Secure VPN OptionAlibaba
Tools & Lab GearAliExpress
Test Hardware & Accessories

TL;DR

You will learn how to build a reliable Java + Selenium automation framework (structure, patterns, waits, reporting, parallelism, CI/CD), and you’ll also get Top 10 legendary Java automation scripts you can reuse in real projects: login, file upload/download, alerts, iframes, dynamic tables, explicit waits, retry, screenshots, parallel TestNG, data-driven tests, and REST + UI integration smoke checks.

Table of Contents

  1. Why Java + Selenium still wins
  2. Production setup (JDK, Maven, TestNG, WebDriver)
  3. Enterprise framework structure
  4. Design rules (POM, SRP, readability)
  5. Wait strategy (how to kill flakiness)
  6. Logging, screenshots, reports
  7. Parallel & cross-browser execution
  8. CI/CD integration (Jenkins-style)
  9. Top 10 Java test automation scripts of all time
  10. Production checklist & best practices
  11. FAQ

1) Why Java + Selenium Still Wins in Enterprise Automation

Java + Selenium remains the most widely adopted browser automation stack in enterprise QA and SDET teams because it is open, flexible, highly integrable, and proven across regulated industries. The real power is not “Selenium scripts”; it’s what happens when you embed Selenium inside a disciplined framework: standardized configuration, stable waits, meaningful reporting, safe parallel execution, and CI/CD-driven feedback loops.

CyberDudeBivash approach: treat your automation framework like a product. It needs architecture, maintainability, security hygiene, and release discipline.

2) Production Setup: Tools You Actually Need

  • JDK (LTS) installed and standardized across team machines and CI runners
  • Maven (or Gradle) for builds, dependencies, profiles and pipeline execution
  • TestNG (or JUnit 5) for runner, grouping, lifecycle, parallelism
  • Selenium WebDriver for browser automation
  • Git for version control + PR reviews
  • CI (Jenkins/GitHub Actions/GitLab) to execute tests on every change

CyberDudeBivash Pro Tip

Most automation “fails” are not Selenium issues. They are framework issues: unstable locators, no wait strategy, weak test design, and no reliable execution environment. Build discipline first, tools second.

3) Enterprise Framework Structure (Clean + Scalable)

A production-grade structure separates responsibilities. Tests should describe business intent; page objects should encapsulate UI mechanics; utilities should provide reusable services (waits, config, files, reporting). A clean baseline:

project-root
├── src/test/java
│   ├── base
│   │   ├── BaseTest.java
│   │   ├── DriverManager.java
│   │   └── TestContext.java
│   ├── pages
│   │   ├── LoginPage.java
│   │   └── DashboardPage.java
│   ├── tests
│   │   ├── LoginTests.java
│   │   └── SmokeSuite.java
│   ├── utils
│   │   ├── Config.java
│   │   ├── Waiter.java
│   │   ├── ScreenshotUtil.java
│   │   └── DataProviderUtil.java
│   └── listeners
│       ├── TestListener.java
│       └── RetryAnalyzer.java
├── src/test/resources
│   ├── config
│   │   ├── qa.properties
│   │   ├── stage.properties
│   │   └── prod.properties
│   └── testdata
│       ├── users.csv
│       └── login.json
├── pom.xml
└── README.md

This structure prevents “spaghetti automation” and makes parallel execution feasible because shared state gets controlled at the base layer.

4) Design Rules That Make Automation Survive Real Life

  • Single Responsibility: page objects should not contain assertions; tests should not contain locators.
  • Readable Tests: a test should read like a business scenario.
  • Stable Locators: prefer IDs or data-test attributes.
  • Deterministic Assertions: assert stable outcomes (URL, title, unique element presence).
  • No Hardcoded Secrets: credentials come from secure stores or CI secrets.

Example: Page Object Model (POM) — Login Page

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;

public class LoginPage {
  private final WebDriver driver;

  private final By username = By.id("username");
  private final By password = By.id("password");
  private final By loginBtn = By.cssSelector("[data-test='login-btn']");

  public LoginPage(WebDriver driver) {
    this.driver = driver;
  }

  public LoginPage open(String url) {
    driver.get(url);
    return this;
  }

  public DashboardPage loginAs(String user, String pass) {
    driver.findElement(username).sendKeys(user);
    driver.findElement(password).sendKeys(pass);
    driver.findElement(loginBtn).click();
    return new DashboardPage(driver);
  }
}

Notice: page object returns the next page object. That’s how you keep tests readable and flows consistent.

5) Wait Strategy: The #1 Fix for Flaky Selenium Tests

If you use Thread.sleep() as your default strategy, your suite will become slow and unreliable. Production automation uses: explicit waits (and sometimes fluent waits) with clear conditions: element visible, clickable, text present, ajax done, loader gone.

Reusable Wait Utility

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class Waiter {
  private final WebDriverWait wait;

  public Waiter(WebDriver driver, int seconds) {
    this.wait = new WebDriverWait(driver, Duration.ofSeconds(seconds));
  }

  public WebElement visible(By locator) {
    return wait.until(ExpectedConditions.visibilityOfElementLocated(locator));
  }

  public WebElement clickable(By locator) {
    return wait.until(ExpectedConditions.elementToBeClickable(locator));
  }

  public boolean urlContains(String part) {
    return wait.until(ExpectedConditions.urlContains(part));
  }
}

CyberDudeBivash rule: waits must be centralized (one utility), not copied across tests. This makes tuning timeouts possible without refactoring hundreds of files.

6) Logging, Screenshots, Reports (Audit-Ready Automation)

In production, a failure without proof is wasted time. Your framework must capture:

  • Screenshot on failure
  • Browser + environment metadata
  • Action logs (what step ran)
  • Clear error details (what exactly failed)

Screenshot Utility (Safe + Simple)

import java.io.File;
import java.nio.file.Files;
import java.nio.file.Path;
import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.WebDriver;

public class ScreenshotUtil {
  public static String capture(WebDriver driver, String testName) {
    try {
      String ts = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMdd_HHmmss"));
      File src = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
      Path outDir = Path.of("target", "screenshots");
      Files.createDirectories(outDir);
      Path dest = outDir.resolve(testName + "_" + ts + ".png");
      Files.copy(src.toPath(), dest);
      return dest.toString();
    } catch (Exception e) {
      return "screenshot_failed";
    }
  }
}

7) Parallel & Cross-Browser Execution (Without Chaos)

Parallel execution is mandatory for fast feedback, but it requires thread-safe driver management. The safest pattern is ThreadLocal: each test thread gets its own WebDriver instance, isolated from others.

ThreadLocal Driver Manager (Core Pattern)

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class DriverManager {
  private static final ThreadLocal<WebDriver> tlDriver = new ThreadLocal<>();

  public static void initDriver() {
    // In production, select browser from config/env and set options safely.
    tlDriver.set(new ChromeDriver());
  }

  public static WebDriver getDriver() {
    return tlDriver.get();
  }

  public static void quitDriver() {
    WebDriver d = tlDriver.get();
    if (d != null) {
      d.quit();
      tlDriver.remove();
    }
  }
}

8) CI/CD Integration (Jenkins-Style Reality)

Automation becomes valuable when it runs automatically on a predictable schedule and on every change. A mature pipeline strategy:

  • PR checks: run a fast smoke suite (2–10 minutes).
  • Nightly: run regression and cross-browser.
  • Pre-release: run full suite with reports + artifacts.

CyberDudeBivash CI Rule

CI must run tests in a clean environment. If developers run locally one way and CI runs another way, your results will never match. Standardize Java version, browser version, and execution flags.

Build Your Automation Career Faster

If you want structured automation and QA learning with real projects, consider these CyberDudeBivash partner options:

Edureka – QA / Selenium TracksGeekBrains – Career ProgramsRewardful – SaaS Affiliate Tools

9) Top 10 Java Test Automation Scripts of All Time (Selenium + TestNG)

These are the most reused, most practical “core scripts” that appear in almost every serious Java/Selenium automation suite. They’re written to be framework-friendly (utilities, POM compatibility, clean waits). Adapt selectors and URLs for your AUT.

Script #1: Production Login Test (POM + Assert + Wait)

@Test
public void login_should_open_dashboard() {
  LoginPage login = new LoginPage(driver).open(Config.baseUrl());
  DashboardPage dash = login.loginAs(Config.user(), Config.pass());
  Assert.assertTrue(dash.isLoaded(), "Dashboard did not load after login");
}

Why it’s legendary: login is your universal gate. If you can’t stabilize login flow, your entire suite breaks.

Script #2: Explicit Wait for Dynamic Element (No Sleep)

WebElement btn = new Waiter(driver, 12).clickable(By.cssSelector("[data-test='save']"));
btn.click();
Assert.assertTrue(new Waiter(driver, 12).urlContains("/saved"));

Why it’s legendary: dynamic UIs fail tests; wait utilities fix the root cause.

Script #3: Dropdown Select (Stable Strategy)

import org.openqa.selenium.support.ui.Select;

Select role = new Select(driver.findElement(By.id("role")));
role.selectByVisibleText("Admin");
Assert.assertEquals(role.getFirstSelectedOption().getText(), "Admin");

Script #4: Handling Alerts (Accept/Dismiss + Text Validation)

driver.findElement(By.id("deleteBtn")).click();

Alert alert = new WebDriverWait(driver, Duration.ofSeconds(8))
  .until(ExpectedConditions.alertIsPresent());

String msg = alert.getText();
Assert.assertTrue(msg.toLowerCase().contains("delete"), "Unexpected alert message: " + msg);
alert.accept();

Script #5: iFrame Switch (Then Return Safely)

driver.switchTo().frame("payment-frame");
driver.findElement(By.id("cardNumber")).sendKeys("4111111111111111");
driver.switchTo().defaultContent();

Assert.assertTrue(driver.findElement(By.cssSelector("[data-test='checkout']")).isDisplayed());

Script #6: File Upload (SendKeys Strategy)

Works when the app uses a real <input type=”file”> element (hidden inputs may require JS or click-to-open behavior first).

String filePath = Path.of("src","test","resources","testdata","sample.pdf").toAbsolutePath().toString();
WebElement upload = driver.findElement(By.cssSelector("input[type='file']"));
upload.sendKeys(filePath);

Assert.assertTrue(driver.findElement(By.id("uploadSuccess")).isDisplayed());

Script #7: File Download Verification (Polling Folder)

Classic “download exists” check. In CI, use a dedicated download directory per run to avoid collisions.

Path downloadDir = Path.of("target","downloads");
Files.createDirectories(downloadDir);

driver.findElement(By.id("downloadCsv")).click();

boolean found = false;
for (int i=0; i<20; i++) {
  try (var s = Files.list(downloadDir)) {
    found = s.anyMatch(p -> p.getFileName().toString().endsWith(".csv"));
  }
  if (found) break;
  Thread.sleep(500);
}
Assert.assertTrue(found, "CSV not downloaded");

Script #8: Dynamic Web Table Search (Reusable)

List<WebElement> rows = driver.findElements(By.cssSelector("table#users tbody tr"));
boolean match = rows.stream().anyMatch(r -> r.getText().contains("bivash@example.com"));
Assert.assertTrue(match, "User row not found in table");

Script #9: Retry Failed Tests (TestNG RetryAnalyzer)

Use retry for transient infrastructure issues only. If tests are flaky due to design, fix design first.

import org.testng.IRetryAnalyzer;
import org.testng.ITestResult;

public class RetryAnalyzer implements IRetryAnalyzer {
  private int count = 0;
  private final int maxRetry = 1;

  public boolean retry(ITestResult result) {
    if (count < maxRetry) {
      count++;
      return true;
    }
    return false;
  }
}

Script #10: UI + API Smoke (Fast Confidence Check)

Elite teams validate “system truth” via API and “user truth” via UI in one short smoke. API code depends on your HTTP client; here’s the UI pattern:

@Test
public void smoke_user_visible_after_api_seed() {
  // Step 1: Seed data via API (pseudo)
  // ApiClient.createUser("qa_user_01");

  // Step 2: Validate via UI
  driver.get(Config.baseUrl() + "/users");
  WebElement search = new Waiter(driver, 10).visible(By.id("search"));
  search.sendKeys("qa_user_01");

  boolean exists = driver.findElements(By.cssSelector("table#users tbody tr")).stream()
    .anyMatch(r -> r.getText().contains("qa_user_01"));

  Assert.assertTrue(exists, "Seeded user not visible in UI");
}

Security Note (Automation Code Is Real Code)

Never store passwords in your repository. Use CI secrets, vaults, or environment variables. Limit report access because screenshots can contain sensitive data. This is a real security surface area, especially in regulated businesses.

10) Production Checklist: What Makes a Framework “Enterprise-Ready”

  • Framework structure with clean separation (base/pages/tests/utils/listeners).
  • Central config per environment (qa/stage/prod) and CI overrides.
  • Stable locators and agreed data-test attributes with developers.
  • Explicit waits standardized via one Wait utility.
  • Thread-safe parallel execution (ThreadLocal drivers, isolated downloads).
  • Failure artifacts (screenshots, logs, environment details).
  • CI/CD integration with smoke/regression strategy and reliable runners.
  • Security hygiene (no secrets in code, protect reports and logs).
  • Maintenance routine (locator audits, flaky test triage, refactoring).

CyberDudeBivash Services

Need a production-grade automation framework, CI integration, or secure QA pipelines for your business? CyberDudeBivash can help with: Framework architecture, SDET mentoring, CI/CD setup, stability engineering, and security-first test automation.

Explore Apps & ProductsVisit CyberDudeBivash

FAQ

Q1) TestNG or JUnit?
Both work. TestNG is still popular for enterprise parallelism, listeners, and suite control. JUnit 5 is excellent too. Choose what your org supports.

Q2) Why do my Selenium tests pass locally but fail in CI?
CI is a different machine, different CPU load, different browser version, different screen size, and often different timing. Fix waits, standardize versions, and isolate test data.

Q3) What is the fastest way to reduce flakiness?
Centralize explicit waits, replace brittle XPaths, stabilize test data, and stop using Thread.sleep as a strategy.

Q4) Should I automate everything?
No. Automate stable, high-value user journeys first (smoke + critical regression), then expand.

Next Reads (CyberDudeBivash)

CyberDudeBivash Main Hub  |  CyberBivash (Intel/CVEs)

#CyberDudeBivash #Java #Selenium #TestAutomation #AutomationFramework #TestNG #JUnit #SDET #QAEngineering #CI_CD #Jenkins #DevSecOps #SoftwareTesting #QualityEngineering #AutomationTesting

Leave a comment

Design a site like this with WordPress.com
Get started