How I Spot a Copy-Pasted Automation Tester Project in Minutes

# What I look at (you can run these on your own repo)

git log --oneline | head -20
#   Copied:  a1b2c3d initial commit
#   Owned:   f9e8d7c add retry-free wait for cart badge
#            c6b5a4e move login locators to LoginPage
#            b3a2f1e add data-driven invalid login cases
#            ...

git log --stat --follow src/test/java/base/BaseTest.java
#   Shows how the core class changed over time

git shortlog -sn
#   Shows who committed; a single unknown author
#   different from the candidate raises a question

# Shop UI and API tests

Selenium 4 + TestNG + REST Assured, Java 17, Maven.

## What is tested
- Login: valid, invalid, locked user (data-driven)
- Cart: add, update quantity, remove
- Checkout API: order created, total matches cart

## Run
    export APP_URL=...  TEST_PASSWORD=...
    mvn test                     # all tests, headless
    mvn test -Dgroups=smoke      # smoke only

Report: target/surefire-reports and ExtentReport in
target/report.html

## Known issues
- Cart badge test was flaky; fixed with an explicit
  wait on the badge text (see commit c6b5a4e).

public class BaseTest {
  public static WebDriver driver;

  @BeforeMethod
  public void setup() throws Exception {
    System.setProperty("webdriver.chrome.driver",
        "C:\\Users\\someone\\drivers\\chromedriver.exe");
    driver = new ChromeDriver();
    driver.manage().window().maximize();
    driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(30));
    Thread.sleep(3000);
    driver.get("...");
  }
}

// Signs: static driver (breaks in parallel), hard-coded
// path from another person's machine, a 30s implicit
// wait plus a sleep, and no teardown method at all.

public class BaseTest {
  private static final ThreadLocal<WebDriver> DRIVER = new ThreadLocal<>();

  protected WebDriver driver() { return DRIVER.get(); }

  @BeforeMethod(alwaysRun = true)
  public void setUp() {
    ChromeOptions options = new ChromeOptions();
    if (Boolean.parseBoolean(Config.get("headless", "true"))) {
      options.addArguments("--headless=new");
    }
    options.addArguments("--window-size=1366,768");
    // Selenium Manager (Selenium 4.6+) finds the driver,
    // so no hard-coded chromedriver path is needed.
    DRIVER.set(new ChromeDriver(options));
    driver().get(Config.get("appUrl"));
  }

  @AfterMethod(alwaysRun = true)
  public void tearDown() {
    WebDriver d = DRIVER.get();
    if (d != null) {
      d.quit();
      DRIVER.remove();
    }
  }
}

// Instead of clicking through the UI to fill a cart,
// create the cart through the API, then test the UI.

@Test
public void cartPageShowsItemsAddedViaApi() {
  String token = Api.loginAndGetToken("cart_user");
  Api.addToCart(token, "SKU-1001", 2);

  // Reuse the session in the browser
  driver().get(Config.get("appUrl"));
  driver().manage().addCookie(new Cookie("auth_token", token));
  driver().get(Config.get("appUrl") + "/cart");

  CartPage cart = new CartPage(driver());
  Assert.assertEquals(cart.quantityOf("SKU-1001"), 2);
}

// Assumes the app accepts the API token as a cookie.
// Check how your target app stores its session first.

DATE      TEST                      SYMPTOM
--------  ------------------------  -----------------------
Week 3    cartBadgeUpdates          Passed locally, failed
                                    in CI about 1 in 4 runs

WHAT I CHECKED
- Screenshot on failure: badge still showed old count
- CI uses headless with smaller default window
- Badge text updates after an async call

CAUSE
Assertion ran before the badge text changed.

FIX
wait.until(ExpectedConditions.textToBe(badge, "2"))
instead of reading the text immediately.

LESSON
Wait for the state I am asserting, not just for the
element to exist.

Answer aloud, without opening the code:

[ ] How did the framework grow? First test to now.
[ ] What does each core class do? (BaseTest, Config,
    Listener, DriverFactory)
[ ] Why that wait strategy?
[ ] Why those locators on the trickiest page?
[ ] How do tests get their data?
[ ] How do you run it in CI?
[ ] Which test was hardest to stabilise, and why?
[ ] What would you change if you started again?

Fewer than six confident answers: spend a weekend
on the upgrade plan before applying.

WEEKEND 1
- Point the tests at a different practice site
- Rewrite locators for the new pages yourself
- Delete every class you do not use or understand

WEEKEND 2
- Add data-driven tests for one form
- Add API calls for test data setup
- Remove Thread.sleep and implicit waits

WEEKEND 3
- Make the driver ThreadLocal and run in parallel
- Run in CI (GitHub Actions or Jenkins), headless
- Write a README with run steps and known issues

Commit small and often, with clear messages.

Prepare one sentence for each:

Origin:    "I started from ___ and changed ___."
Scope:     "It covers ___ flows on ___ site."
Design:    "I used POM because ___, and ___ for data."
Stability: "The hardest test was ___ because ___."
CI:        "It runs on ___ with ___ reports."
Next:      "With more time I would add ___."

Six sentences, all true, all yours. That is a
project explanation no copied repository can match.