Framework Milestone 6: Hybrid Tests

Why it matters

Signing in through the form in every test is slow and makes unrelated tests fail when the login page breaks. Hybrid tests are a clear sign of a mature framework.

What to build

Sign in by API. Call POST /api/cover/login, then give the browser the dc_session cookie and open a page directly, skipping the login form.
Set up by API, check in the UI. File a claim through the API, then open its page and check the details and status on screen.
Act in the UI, check by API. Approve a claim in the browser as the adjuster, then read it through the API and check the status, payout and version.
A conflict. Open a claim in the browser, change it through the API, then save in the browser and check that the conflict message appears.

Rules

Only the login page tests use the login form.
Data a test needs is created by that test, through the API.
Each hybrid step is a reusable helper, not code copied between tests.

Hints

Selenium

A browser only accepts a cookie for the site it is on: open any DojoCover page first, then driver.manage().addCookie(new Cookie("dc_session", token)) (or your language's equivalent), then go to the page you want.

Playwright

Use context.addCookies([{ name: "dc_session", value: token, url: baseURL }]), or sign in once and reuse storageState across tests.

These are pointers, not solutions. TestDojo doesn't publish a finished framework: the point is that you build and understand your own.

Done when

UI tests outside the login tests start already signed in, via the API
At least one test sets up data by API and checks it in the UI
At least one test acts in the UI and checks the result by API
The conflict test passes
The suite is noticeably faster than before this milestone

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.

What is a hybrid test, and why use one?: API for setup and checks, UI for the behaviour under test: faster, less flaky, and failures point at the real problem.
How do you avoid logging in through the UI in every test?: Sign in by API and inject the session cookie or saved storage state.
How do you test two users acting on the same record?: Separate sessions or contexts, and checking the conflict handling.

Note the decision you made in this milestone and why. Those notes become your README in milestone 9.