Setup & Environment
Before you write a single test, your tools must be stable. Learn how to build a reproducible automation environment that won't break when you share it with the team.
1 The Hook — Why This Matters
In 2023, a Wellington SaaS startup onboarded a new junior automation engineer. They cloned the repo, ran pytest, and every test failed with BrowserType.launch: Executable doesn't exist. The team had installed Playwright three months earlier but never documented the playwright install step in the README.
The new hire spent two days reinstalling Python, swapping Node versions, and editing system PATH variables before a senior engineer spotted the missing browser binaries. One undocumented command cost the team forty hours of billable time and delayed a release by a full sprint.
If your environment isn't reproducible, you're not testing the application — you're testing your laptop.
2 The Rule — The One-Sentence Version
Your test environment must be reproducible from a fresh machine in under fifteen minutes, or it is not done.
When tests fail on a colleague's computer but pass on yours, the defect is rarely in the application. It is in the environment. Virtual environments, pinned dependency versions, and documented setup steps are the foundation that lets you trust your results.
3 The Analogy — Think Of It Like...
Building a race car in a shared garage.
If your tools are scattered, the torque wrench is missing, and the pneumatic line only works on Tuesdays, you can't tell whether the engine tuning made the car faster or the garage just had a bad air day. A stable environment is the workshop. The test is the tuning. Fix the workshop first.
4 Watch Me Do It — Step by Step
Here is a standard Playwright + Python setup. Follow these steps every time you start a new automation project.
-
Create a virtual environment
Isolate dependencies so they don't collide with other projects.
python -m venv .venv .venv\Scripts\activate <-- Windows source .venv/bin/activate <-- Mac/Linux -
Install the test packages
Pin versions in
requirements.txtor use a lock file.pip install pytest-playwright pip freeze > requirements.txt -
Install browser binaries
This is the step everyone forgets. The Python package does not include Chromium, Firefox, or WebKit.
playwright install -
Verify with a smoke test
Run a single trivial test to confirm the browser launches.
pytest --headed -k test_smoke - Document in your README The next engineer should not have to guess. Copy the exact commands into the project readme.
| Language | Tool | Install command |
|---|---|---|
| Python | pip | pip install pytest-playwright |
| JavaScript | npm | npm install @playwright/test |
| Java | Maven | <dependency> selenium-java </dependency> |
| Pitfall | Symptom | Fix |
|---|---|---|
| PATH not set (Windows) | 'python' is not recognized | Add Python install dir and Scripts folder to system PATH |
| Missing browser binaries | Executable doesn't exist | Run playwright install |
| Driver mismatch (Selenium) | Session not created | Use webdriver-manager to auto-resolve versions |
5 When to Use It / When NOT to Use It
✅ Invest time in setup when...
- Starting a new automation project
- Onboarding a new team member
- Configuring CI/CD pipelines
- After major OS or browser updates
- The existing suite has dependency conflicts
❌ Skip the full rigour when...
- The environment is already stable and documented
- Writing a one-off debugging script
- The project lifespan is shorter than the setup time
- You are pairing on someone else's configured machine
Before you apply this technique, ask:
- Are you using a virtual environment, not global packages?
- Have you tested on a fresh clone to ensure setup is repeatable?
- Is your setup documented for team onboarding?
6 Common Mistakes — Don't Do This
🚫 Installing packages globally
I used to think: Running pip install without a virtual environment is faster and simpler.
Actually: Global installs create version conflicts across projects. The day you need Selenium 4 in one repo and Selenium 3 in another, you'll spend hours debugging ImportError messages. A virtual environment costs ten seconds and saves ten hours.
🚫 Forgetting browser binaries
I used to think: Installing pytest-playwright gives you everything you need.
Actually: The Python package is just the wrapper. The actual Chromium, Firefox, and WebKit binaries are downloaded separately by playwright install. If your CI image caches these, document which version it caches. If your colleague's machine is fresh, they will hit this error every time.
🚫 Ignoring PATH on Windows
I used to think: If python isn't recognised, I should reinstall it.
Actually: Reinstalling rarely fixes PATH issues. On Windows, open Environment Variables and add both the Python install directory and its Scripts subfolder to the system PATH. Then open a new terminal. Test with python --version before touching the installer again.
When this technique fails
If setup works for you but not teammates, you probably used global Python without documenting venv setup. Or you installed browser binaries but didn't mention it. Fresh-clone failures are the biggest onboarding killer.
7 Now You Try — Interview Warm-Up
Scenario: A new teammate clones your repo, creates a virtual environment, runs pip install -r requirements.txt, and then pytest. Every test fails with BrowserType.launch: Executable doesn't exist. They have followed your README exactly.
What single command is missing from the README?
The missing command:
playwright installThe Python package and the browser binaries are distributed separately. This is by design — it keeps the PyPI package small and lets you choose which browsers to install. Always document this step explicitly, because it is the #1 setup failure in new Playwright projects.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. Why is a virtual environment essential for automation projects?
It isolates project dependencies so version conflicts between packages (like Selenium 3 vs 4) cannot break your suite. It also makes your environment reproducible: a teammate can create an identical one with two commands.
Q2. What does playwright install do that pip install pytest-playwright does not?
It downloads the actual browser binaries (Chromium, Firefox, WebKit). The pip package only installs the Python wrapper and test runner integration. Without the binaries, Playwright cannot launch any browser.
Q3. A Selenium test fails with "Session not created" after a Chrome update. What is the quickest fix?
Use webdriver-manager to auto-resolve the ChromeDriver version, or pin both Chrome and ChromeDriver versions in your CI environment. Manual version matching is brittle and wastes time on every browser update.
9 Interview Prep — Junior Q&A
Interviewers ask about environment setup to understand whether you think about reproducibility and whether you can troubleshoot configuration issues.
Q. "A new teammate clones the repo and the tests fail immediately. What's your first debugging step?"
I'd check the README. Did they follow the setup steps? Specifically: virtual environment activated, dependencies installed (pip install -r requirements.txt), and for Playwright, did they run "playwright install"? That last step is the #1 miss. If they did all that, I'd check the error message: is it a Python version mismatch, a missing environment variable, or a system PATH issue?
Q. "Why should setup take under 15 minutes on a fresh machine?"
Because if it takes longer, it becomes a bottleneck for onboarding and CI/CD. Every new team member wastes hours debugging. CI runners need fresh images. If your environment isn't reproducible in 15 minutes, you have hidden dependencies or undocumented steps. This signals sloppiness to interviewers.
Q. "What's the difference between installing packages globally vs. in a virtual environment?"
Global installs pollute your system Python and create version conflicts across projects. If Project A needs Selenium 3 and Project B needs Selenium 4, global installs break one or the other. Virtual environments isolate dependencies, so each project can have exactly the versions it needs without conflicts. They also make CI reproducible.
Q. "How would you document setup for a Windows user if you normally work on Mac?"
I'd include platform-specific commands: e.g., show both "source .venv/bin/activate" (Mac/Linux) and ".venv\Scripts\activate" (Windows). I'd document PATH issues explicitly for Windows because they're common. I'd also test the setup on both platforms before claiming it's "done." Ideally, I'd use Docker or a scripted setup (like a Makefile or a shell script) to ensure consistency across platforms.