How it works

  1. Create a practice account in DojoCover. You get a private copy of the app with customer, adjuster, manager and admin logins.
  2. Build on your own machine, in your own GitHub repository. Each milestone says what to build and how you'll know it's done.
  3. Tick off each milestone as you finish it. Progress is saved in this browser and shown in the sidebar.
  4. Prepare to explain it. Every milestone lists the interview questions it gets you ready for.

The API reference describes every DojoCover endpoint. You'll need Git, a GitHub account, and the tools for your language installed. The Selenium and Playwright setup guides cover installing them.

The app you'll test: DojoCover

A fictional insurance claims portal with made-up data. Customers file claims with documents, adjusters review them and ask for more information, and managers approve claims above the adjuster's limit. Every screen has a REST API behind it, so you can test the UI, the API, and both together.

The milestones

  1. 1Set up your projectAn empty folder becomes a Git repository with your chosen tools, a clear folder layout and one passing test that signs in to DojoCover.
  2. 2ConfigurationYour tests read the base URL, browser, headless mode, timeouts and credentials from configuration, with environment variables able to override anything.
  3. 3Page and component objectsTests describe what a user does, such as signing in, searching policies or filing a claim, while page and component objects know how to find and use the elements.
  4. 4Test foundationEvery 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.
  5. 5API layerYour framework talks to the DojoCover API directly: it signs in, reads and creates data, and checks status codes, response bodies and validation errors.
  6. 6Hybrid testsTests use the API for setup and checks, and the browser only for what really needs the UI, so they are faster and fail for the right reasons.
  7. 7Test data and full journeysTest data lives outside the code, the same test runs for many inputs, and the most important journeys run end to end across every role.
  8. 8Reliability, reports and CI/CDThe suite runs in parallel, every failure explains itself with a report and a screenshot, and GitHub Actions runs it on every push, every pull request and on a schedule.
  9. 9Portfolio and interviewSomeone who has never seen your repository understands what it does, how it's built and how to run it, and you can walk them through it in a few minutes.

Interview revision list

Every question the milestones prepare you for. Once you can answer each one about your own framework, you're ready.

1. Set up your project

  • Why did you choose this tool and language?
  • How is your project organised?
  • How do you keep credentials out of the code?

2. Configuration

  • How do you run the same tests against different environments?
  • Where do secrets live in your framework?
  • How would you add a new browser?

3. Page and component objects

  • What is the Page Object Model, and why use it?
  • Page objects or component objects: when do you use each?
  • How do you choose locators?
  • Where do your assertions go?

4. Test foundation

  • How do you handle waits?
  • How do you keep tests independent?
  • How do you find the cause of a flaky test?

5. API layer

  • How do you test an API?
  • How is your API layer structured?
  • UI tests or API tests: which do you write more of?

6. Hybrid tests

  • What is a hybrid test, and why use one?
  • How do you avoid logging in through the UI in every test?
  • How do you test two users acting on the same record?

7. Test data and full journeys

  • How do you manage test data?
  • What is data-driven testing?
  • How do you choose what runs in a smoke suite?

8. Reliability, reports and CI/CD

  • How do you run tests in CI?
  • How do you make parallel runs safe?
  • Do you use retries?
  • What happens when the nightly run fails?

9. Portfolio and interview

  • Walk me through your framework.
  • What would you change if you started again?
  • How would this scale to a team of five?

Ground rules

  • It's your framework: TestDojo publishes no finished solution, and an interviewer will ask about your decisions.
  • Use made-up details in DojoCover, and never commit passwords. Keep them in environment variables and, later, CI secrets.
  • Be kind to the shared server: run scheduled CI nightly or weekly, not every few minutes.