Framework Milestone 2: Configuration

Why it matters

The same suite has to run on your machine, a teammate's machine and in CI, against different environments. Hard-coded values are the first thing that stops that.

What to build

A config file per environment. For example local and ci: base URL (https://testdojo.dev/cover), API base (https://testdojo.dev/api/cover), browser, headless, and default timeout.
Environment variables win. Any setting can be overridden, for example BROWSER=firefox or HEADLESS=false, without editing a file.
Secrets from the environment only. User IDs and passwords come from environment variables or a local file that Git ignores. Commit an example file with placeholders instead.
One place that reads it. A single config class or module that the rest of the framework asks for settings. Tests never read environment variables themselves.

Rules

No URL, password or user ID appears in test code.
A missing required secret stops the run at the start with a clear message, not halfway through with a confusing error.
The local secrets file is listed in .gitignore.

Hints

Selenium

Create the driver from the config: the browser name chooses ChromeDriver, FirefoxDriver or EdgeDriver, and headless becomes a browser option. Keep this in one factory method.

Playwright

Put the base URL and browser projects in playwright.config and read values with process.env (or your language's equivalent). Tests can then use paths like page.goto("/login").

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

Done when

Switching browser is a one-line setting or an environment variable
Headless and headed runs are switched the same way
Searching the tests for testdojo.dev or your password finds nothing
A missing password stops the run with a clear message
An example config with placeholders is committed; the real one is ignored

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 run the same tests against different environments?: Per-environment config, a selector such as ENV=staging, and environment variables overriding files.
Where do secrets live in your framework?: Never in the repo: local ignored files or environment variables, and CI secrets in the pipeline.
How would you add a new browser?: A change in the driver or browser factory and the config, not in the tests.

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