Milestone 4 of 9
Test foundation
Every test starts its own browser and data, waits for conditions instead of time, cleans up after itself, and passes alone or with the rest, in any order.
Why it matters
Most flaky suites are flaky because of shared state and fixed sleeps. Getting this right early saves weeks of chasing random failures.
What to build
- Setup and teardown. A base test class, fixtures or hooks that start the browser before each test and always close it afterwards, even when the test fails.
- Independent tests. Each test signs in for itself and doesn't rely on another test having run first.
- Clean data. Before the suite, reset your DojoCover data so it starts from the sample data: Your account → Reset data in the app for now. Milestone 5 does it through the API.
- Wait helpers. Wait for DojoCover's loading indicator (
[data-testid=loading]) to disappear, and for toasts and status badges to change, with explicit conditions and a timeout.
Rules
- No fixed sleeps anywhere: no
Thread.sleep,time.sleeporwaitForTimeout. - A test never depends on the order tests run in.
- A failing test still closes its browser.
Hints
Selenium
Use WebDriverWait with expected conditions, set the implicit wait to zero to avoid mixing the two, and quit the driver in @AfterMethod / teardown.
Playwright
The test runner gives each test a fresh context through the page fixture. Put shared steps in fixtures or beforeEach, and rely on locator auto-waiting plus web-first assertions.
These are pointers, not solutions. TestDojo doesn't publish a finished framework: the point is that you build and understand your own.
Done when
Ticks are saved in this browser only, for your own tracking.
In an interview
Questions this milestone prepares you for, and what a good answer covers. Answer them in your own words, about your own framework.
- How do you handle waits?
- Explicit waits for conditions, why fixed sleeps are slow and still flaky, and why implicit and explicit waits shouldn't be mixed.
- How do you keep tests independent?
- Own setup per test, no shared state, and resetting or creating data rather than relying on what another test left.
- How do you find the cause of a flaky test?
- Reproducing it repeatedly, checking timing, shared data and order, and fixing the cause instead of adding retries.
Note the decision you made in this milestone and why. Those notes become your README in milestone 9.