🚀 We Built a Shared Test Automation Infrastructure for Web Projects — Here’s How We Did It

We established a sustainable, scalable, and team-friendly test automation infrastructure for our web projects within the Marketplace ecosystem. In this post, I’ll walk you through why we built this system, how we designed it from a technical standpoint, and how we integrated it into our development workflows.

🎯 1. The Purpose and Benefits of Automation

In modern software development — especially in microservice-based, multi-team environments — test automation is a cornerstone for safe deployments. Our main goals were:

• Establish a centralized and shared test infrastructure for web projects owned by different teams
• Reduce manual testing effort, minimize human error, and save time
• Prevent bugs in production through a reliable regression pipeline
• Build a maintainable, extensible, and easily integrable infrastructure

We set out to support the following key projects:

• getir.com
• GetirYemek Panel
• GetirÇarşı Panel
• GetirSu Panel
• Getirİşyerim

By unifying these projects under a single automation framework, we could standardize our testing strategy and significantly reduce maintenance overhead. We also built a centralized utility pool by abstracting out repetitive logic across tests.

🏗️ 2. How We Built the Infrastructure

We initially used Cypress for test automation in the restaurant panel.

Cypress test example

We initially used Cypress for test automation in the restaurant panel.

Despite Cypress’s strengths, we began to encounter limitations as our needs evolved — such as support for monorepo structures, domain-based test execution, and multi-team parallel development.

Cypress, by design, doesn’t support multi-tab or multi-window scenarios. Also, since it only runs stably on Chromium-based browsers, it limited us on projects requiring cross-browser testing.

This made the switch to Playwright a pivotal decision.

Playwright test example

🔄 Migrating from Cypress to Playwright

Test automation has long been a core part of our development workflow. In the restaurant panel, we built a solid test suite using Cypress that provided significant coverage.

However, new challenges emerged:

• Rapid growth in project count
• Increasingly obvious technical limitations in Cypress
• Deprecation of some plugins we relied on

We needed a more general-purpose, flexible, and future-proof testing platform. After evaluating several options, Playwright stood out.

While leaving behind the familiar Cypress ecosystem wasn’t easy — given its plugin ecosystem and simple API — we found Playwright offered major advantages:

• Faster test execution
• Native support for Chromium, Firefox, and WebKit
• A powerful API for defining high-level test scenarios
• More flexible CI/CD integration
• Well-structured and up-to-date documentation

These strengths helped us shift toward a model where testing is not just an afterthought, but a core part of product development.

Playwright’s lower-level API access, rich platform support, and parallel execution made it ideal for our setup — especially in terms of cross-browser testing and team autonomy.

We also gained flexibility in building custom plugins, helping us overcome some of Cypress’s limitations.

For example, Cypress’s session feature allowed shared login setups across tests. In Playwright, we replicated this using the BrowserContext API—achieving similar efficiency.

🧩 Team-Based Test Structure

Since each team focuses on different pages and flows, we designed the infrastructure around team ownership:

• All tests live in a single monorepo
• Each team manages its own test directories
• Shared utilities, fixtures, and helpers live in a centralized folder
• Tests are tagged with team and domain metadata

🔖 Tagging System

We use two tag types to categorize and filter tests:

• Team tags → team:atlas, team:nova, team:orbit
• Domain tags → domain:vega, domain:echo, domain:quantum

Team tags example

This gives us key benefits:

• Teams can run only their own tests
• Domain-specific test runs are possible in CI/CD
• Builds are faster since only relevant tests are executed

⚙️ 3. Integrating Tests Into Development Workflows

🌙 Nightly Build System

Manual regression testing was time-consuming and inefficient, so we implemented a Nightly Build System:

• All test scenarios run on the dev environment every night
• Failures are automatically reported to our Slack channel
• Logs and screenshots are attached for easier debugging

This allows us to detect UI or functional issues early and take immediate action.

🌐 Real Dev Environment & Mock Tests

Most tests run end-to-end on the actual development environment. But for unstable or third-party-dependent cases, we use mock data:

• Frequently changing or third-party APIs
• Pages requiring login or unique user sessions
• Rare or hard-to-access user roles

Mocking helps us keep these edge cases stable and deterministic.

🔁 CI/CD Integration

Our Playwright tests are not just for nightly runs — they’re embedded directly into our backend pull requests.

• Each microservice pipeline runs only the relevant tests using a tagging script
• This ensures only impacted features are tested
• Test logs and screenshots are displayed inline in the pipeline interface for quick troubleshooting

🔧 Focus on Maintainability

One of our guiding principles was building a structure that would remain maintainable long-term.

Here’s what we focused on:

• Modularity: Shared logic lives in utils/ and setup/ folders, so new tests can be added without affecting others
• Tagging: Lets us run isolated tests by team or domain, improving traceability and control
• Standardization: We enforce consistent coding style and folder structure across teams, so ownership changes don’t degrade test quality
• Documentation: A small but powerful guide covers test structure, conventions, and examples, easing onboarding

🧩 4. Wrap-Up and Future Plans

This shared infrastructure has been transformative:

✅ A 16-person frontend + QA team collaborates in a single repo ✅ Tests are taggable and team/domain-scoped ✅ The framework can easily scale to new projects

🎯 Our goal is not just to write tests, but to make them an active part of development

Testing is no longer just a “safety net” — it’s part of our production line. Code quality is higher, QA is faster, and shipping to production is less stressful.

🔭 What’s Next?

Here’s what we’re working on to further improve the system:

• Lightweight test runs for faster PR feedback
• Scaffolding tools to auto-generate test helpers
• Scenario-based pipelines for staging environments
• A visual dashboard to monitor test outcomes
• More robust visual regression testing

We’re also exploring LLM-assisted test generation to accelerate test authoring for repetitive scenarios.

🚀 Building this system wasn’t just a technical win — it strengthened collaboration across teams. Now we ship more confidently, encounter fewer bugs, and enjoy a smoother development experience.

📬 If you’re working on something similar, feel free to share your experiences or ask any questions in the comments — I’d be happy to help!