Where DSA actually shows up in a real test suite

Problem

All tests share one live account. If logout runs early it can revoke the session every other test is using. If the settings tests run alongside the read-only checks, they change the data those checks read.

Idea

Each stage is a node and each "must run after" rule is an edge. Playwright runs projects in topological order of that graph. CI does the same thing one level up with job needs:.

Impact

Login happens once, and logout is guaranteed to run last. Selenium copies the same order with TestNG <test> blocks, so both suites see the account in the same state.

Cost

Topological sort is O(V + E). Here V = 5 projects, so the value is correctness, not speed.

playwright-ts/playwright.config.ts · .github/workflows/tests.yml

setup ──► app ──► settings ──► logout        (Playwright projects)
playwright ──► selenium ──► dashboard        (CI jobs)

{ name: 'settings', dependencies: ['app'] },
{ name: 'logout',   dependencies: ['settings'] },

Problem

The app updates the screen first and saves in the background. Reloading before the save request goes out cancels it, and the test then sees the old value. Selenium's default WebDriverWait polls every 500 ms, so it kept noticing the save late.

Idea

Stop asking "is it done yet?" on a timer. Subscribe to the network over WebDriver BiDi and let the PATCH response itself release a CountDownLatch.

Impact

Each save check dropped from about 533 ms to about 228 ms, close to Playwright's built-in waitForResponse. The reload that verifies each step only runs after the save has landed.

Cost

Polling has worst-case lag equal to the poll interval. An event has none, so you wait only as long as the server takes.

selenium-java/.../pages/ProfilePage.java · clickAndWaitForSave()

CountDownLatch saved = new CountDownLatch(1);
network.onResponseCompleted(response -> {
    if ("PATCH".equals(response.getRequest().getMethod())
            && response.getRequest().getUrl().contains("/rest/v1/profiles")
            && response.getResponseData().getStatus() / 100 == 2) {
        saved.countDown();
    }
});
click.run();
if (!saved.await(10, TimeUnit.SECONDS)) throw new TimeoutException(...);

Problem

Playwright writes JSON and Selenium writes Surefire XML. Each test is named differently in each one. The results page needs one row per test case showing both outcomes.

Idea

Index each report once into a Map keyed by test name, then walk the 39 test cases and look each one up. This is the Two Sum trick: trade a little memory for constant-time lookups.

Impact

The dashboard can say "same result in both frameworks" and highlight any test where they disagree.

Cost

O(n + m) to build and join, instead of O(n × m) for a nested loop.

dashboard/build.mjs

const pw = new Map();                       // title -> { status, ms }
pw.set(spec.title, { status, ms: last?.duration ?? 0 });

const rows = cases.map(c => ({ ...c, pw: pw.get(c.playwright) ?? null, se: findSe(c.selenium) }));

Problem

Each framework card shows passed, failed, skipped, flaky and "not run" totals.

Idea

One pass over the rows, incrementing a counter per status. It is the same pattern as character frequency or Python's Counter. A missing result counts as its own bucket instead of crashing the build.

Impact

One function serves both frameworks, and a test that silently did not run shows up as "missing" instead of being dropped.

Cost

O(n) time, O(k) space for k statuses.

const tally = side => {
    const t = { passed: 0, failed: 0, skipped: 0, flaky: 0, missing: 0 };
    for (const r of rows) t[r[side]?.status ?? 'missing']++;
    return t;
};

Problem

Playwright's JSON report is a tree: files contain describe blocks, which contain more describe blocks and then specs. The depth is not fixed.

Idea

A depth-first walk that handles the specs at the current node and then recurses into each child suite, the same shape as Maximum Depth of a Binary Tree, but for an n-ary tree.

Impact

Nested test.describe blocks just work. Adding a new level of grouping to the tests does not break the dashboard.

Cost

O(nodes). Recursion depth equals nesting depth, which is about 3 here.

const walk = suite => {
    for (const spec of suite.specs ?? []) { /* record each test */ }
    (suite.suites ?? []).forEach(walk);
};
report.suites.forEach(walk);

Problem

Several parts of the app have no roles or labels to target: history dates, kalam times, stat tiles.

Idea

Use tree vocabulary directly. div[not(*)] means "leaf nodes only", .. is the parent pointer, and h1 + * is the next sibling.

Impact

Matching the date regex against leaves only avoids false hits on container divs, whose text includes all their children.

Cost

One scan of the subtree under main.

selenium-java/.../pages/HistoryPage.java

private final By leafDivs = By.xpath("//main//div[not(*)]");   // leaves of the DOM tree
driver.findElements(leafDivs).stream().map(BasePage::text).filter(t -> t.matches(ENTRY_DATE)).toList();

Problem

Logging in through the UI is blocked by a Cloudflare captcha, and minting a session for every test is slow. Separately, the app paints a cached profile before the server copy arrives, so a check can pass on stale data.

Idea

Compute the session once and reuse it. Playwright saves it to a storageState file in a setup project. Selenium keeps it in a lazily filled, synchronized static field. For the stale profile, invalidate the cache key, reload, and wait until the app rewrites it from the server.

Impact

One admin magic-link call per run instead of one per test, and no false passes from stale cached values.

Not an LRU

It is a cache with exactly one entry, no eviction policy, and the token's own expiry as a TTL. An LRU cache needs a fixed capacity and evicts the least recently used entry, and nothing here does that.

// Selenium: compute once, reuse (memoized singleton)
public static synchronized String sharedSessionJson() {
    if (shared == null) shared = createSessionJson();
    return shared;
}

// Playwright: invalidate, reload, wait for the fresh write
await page.evaluate(key => localStorage.removeItem(key), ProfilePage.CACHE_KEY);
await page.reload();
await page.waitForFunction(key => localStorage.getItem(key) !== null, ProfilePage.CACHE_KEY);

Problem

The navigation test visits all six tabs, and the failure report should list them in the same order as on screen.

Idea

Java's LinkedHashMap is a hash map with a doubly linked list running through its entries, so iteration follows insertion order. TypeScript objects with string keys keep insertion order too.

Impact

The tab tests run in a stable order every time, so a failure always means the same thing.

Interview link

This is the exact structure behind LRU Cache (#146). Construct it with accessOrder = true and override removeEldestEntry, and you have an LRU. The suite uses insertion order only.

public static final Map<String, String> TABS = new LinkedHashMap<>();
static { TABS.put("Today", "/"); TABS.put("Learning", "/learning"); /* ... */ }

Problem

Seven login validation checks would mean seven nearly identical test bodies.

Idea

One table of rows (an Object[][] TestNG DataProvider and a TypeScript array), one test body. The cases sit exactly at the boundary: a 7-character password must fail and an 8-character password must pass.

Impact

Adding a case is one line. The 7 vs 8 pair is the off-by-one check that catches a < written where <= was meant.

{ "password 7 chars",  "password", "1234567",  "tooShort" },
{ "8 char password",   "password", "12345678", "valid"    },

Problem

"Shows three kalams" is not enough. A fourth unexpected kalam, or the right count with a wrong name, should both fail.

Idea

Build a map of name to time from the page and assert its key set equals the expected set exactly. The Learning test does the same with a count plus membership for all 14 practices.

Impact

Catches extras and missing items in one assertion, with a readable diff.

assertThat(kalams).containsOnlyKeys("Rahu Kalam", "Yamagandam", "Gulika Kalam");

Problem

Find the first anushtanam not yet tracked, and match Selenium results whose names carry DataProvider parameters.

Idea

Stream, filter, and stop at the first hit (findFirst, anyMatch). For Selenium names, a prefix match, because validation[bad email format, ...] starts with the key stored in the test case list.

Trade-off

The prefix lookup scans the whole map, so the join is O(n × m) for those rows. With 39 rows that is about 1,500 string checks, which is nothing. If this grew to thousands of tests I would normalise the keys once and go back to O(1) lookups.

const findSe = name => {
    for (const [key, value] of se) if (key === name || key.startsWith(name)) return value;
    return null;
};

Problem

These tests run against production with a real account. Any test that changes data has to leave it exactly as it found it.

Idea

Every write is paired with its inverse: switch a setting and switch it back, add a child and remove it, Next and then Previous. The start state is read first, and the two targets are chosen with a swap so the test works whichever option is currently on.

Impact

The suite can run on every push without slowly corrupting the account. The two writes with no inverse in the app yet are opt-in only and stay skipped in CI.

const [from, to] = await profile.isChipOn(a) ? [a, b] : [b, a];
for (const target of [to, from]) { /* click, wait for the save, verify after a fresh reload */ }