Build your own framework
Nine milestones that take you from an empty folder to a hybrid UI and API framework that runs on a schedule in CI. You write every line, in the tool and language you choose, against DojoCover, a practice claims app made for this.
How it works
- Create a practice account in DojoCover. You get a private copy of the app with customer, adjuster, manager and admin logins.
- Build on your own machine, in your own GitHub repository. Each milestone says what to build and how you'll know it's done.
- Tick off each milestone as you finish it. Progress is saved in this browser and shown in the sidebar.
- 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
- 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.
- 2ConfigurationYour tests read the base URL, browser, headless mode, timeouts and credentials from configuration, with environment variables able to override anything.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.