Extending My Agentic SDLC Demo: Adding Vibium Test Support Alongside Playwright

*Posted by Beth Marshall | January 12, 2026 – hand reviewed but drafted by Cursor*

After building my initial [Agentic SDLC demo] with Playwright, I wanted to explore supporting multiple browser automation frameworks. This would demonstrate framework flexibility and provide a comparison point between different testing tools. I decided to add **Vibium** support alongside the existing Playwright implementation.

Now there are a few things to note here:-

1. I appreciate that you’d never normally need to put two automation mcp servers in the same solution side by side. It duplicates test code and for anything other than a demo it is not a good idea.
2. Vibium is still new in its journey (only released Christmas ’25) and has a lot of cool features still being worked on – see its Roadmap for full details. I tried to make sure the tests had feature parity and similar coverage between the two frameworks for a fair comparison, but it would be worth expanding the tests and repeating the exercise as both Vibium and Playwright evolve.

TLDR: Where’s the code

You can check out the completed code here: https://github.com/askherconsulting/AI_SDLC_MCP

## The Goal

I wanted to maintain both Playwright and Vibium implementations in the same codebase, ensuring:

– Both frameworks test the same functionality

– Tests can run independently or together

– The codebase remains maintainable and well-organized

– CI/CD works seamlessly with both frameworks

## Organizing the Code Structure

The first challenge was organizing the code to support both frameworks without duplication or confusion. I settled on a clear directory structure:

“`

tests/

├── helpers.ts              # Shared utilities (framework-agnostic)

├── playwright/             # Playwright test implementations

│   ├── example.spec.ts

│   ├── health.spec.ts

│   └── pictures.spec.ts

└── vibium/                 # Vibium test implementations

    ├── example.spec.ts

    ├── health.spec.ts

    └── pictures.spec.ts

“`

This separation keeps each framework’s tests isolated while sharing common utilities like server health checks.

## Key Implementation Challenges

### 1. Test Parity

**Problem:** Playwright had additional test coverage (file uploads, computed styles) that Vibium couldn’t easily replicate.

**Solution:** Aligned both test suites to have equivalent coverage:

– Removed Playwright’s actual file upload (kept form validation only)

– Removed computed style verification (kept element existence checks)

– Standardized waiting strategies (using timeouts instead of framework-specific wait methods)

This ensures both frameworks test the same functionality, making comparisons fair and meaningful.

### 2. CI/CD Integration

**Problem:** Vibium tests were unreliable in GitHub Actions, timing out or failing due to missing dependencies. Could well have been an error in my understanding, but Playwright tests ran immediately and despite multiple efforts I just couldn’t get the Vibium tests to work. I did ensure both still work locally though, and the README.md provides the requisite commands.

**Solution:**

– Initially tried running both frameworks in CI

– Encountered issues with Vibium’s browser launch in headless CI environments

– Decided to run only Playwright tests in CI for reliability

– Vibium tests remain available for local development

The workflow now:

– Installs Playwright browsers

– Runs Playwright tests

– Vibium tests can be run locally with `npm run test:vibium`

There were various other technical issues which required Cursor and myself to fix, but the whole thing was the result of an hour or so of work.

## Final Test Structure

Both test suites now cover the same functionality:

1. **Homepage** – Verifies page loads with correct heading

2. **Health Endpoint** – Validates JSON response structure

3. **Pictures Page** – Tests:

   – Page content and headings

   – Navigation links

   – Navigation functionality

   – Upload form elements

   – Empty state message

   – Form validation (without actual upload)

   – Gallery image display

   – Container element consistency

## Running the Tests

The project now supports multiple test commands:

“`bash

# Run all tests (both frameworks)

npm test

# Run only Playwright tests

npm run test:playwright

# Run only Vibium tests

npm run test:vibium

# Run both frameworks sequentially

npm run test:all

“`

## Performance Results – headless mode

## Key Learnings

1. **Framework Comparison:** Having both implementations side-by-side makes it easy to compare API differences, performance, and capabilities.

2. **Platform-Specific Dependencies:** `optionalDependencies` is essential for packages that only work on specific platforms.

3. **Auto-Configuration:** Helper functions that auto-detect and configure environment variables reduce setup friction for developers.

4. **Test Parity:** Aligning test coverage ensures fair comparisons between frameworks.

5. **CI/CD Pragmatism:** Sometimes it’s better to run the most reliable tests in CI and keep others for local development.

6. **Cross-Platform Scripts:** Explicit file lists are more reliable than glob patterns across different shells.

## What’s Next?

This dual-framework setup provides a solid foundation for:

– Comparing framework performance and reliability

– Demonstrating framework flexibility in portfolio projects

– Learning different browser automation APIs

– Building more robust test suites that aren’t tied to a single framework

The codebase is now a living example of how to maintain multiple testing frameworks in harmony, with shared utilities and equivalent test coverage. Interestingly, the playwright tests are currently a little faster than vibium, but that seems to be due to a chrome.exe authorisation check and failure taking extra time.

I think further exploration would of course need to optimise for areas like security, accessibility and other important devops concerns. This isn’t an enterprise or scalable solution, but nor is it a codebase that that the LLM hasn’t already been trained on.

## Resources

– [Original Agentic SDLC Demo Post](https://beththetester.com/2026/01/10/how-i-built-an-agentic-sdlc-demo-with-cursor-mcp-servers-playwright-github-and-vercel-in-under-an-hour/)

– [Playwright Documentation](https://playwright.dev/)

– [Vibium GitHub](https://github.com/vibium/vibium)

– [MCP Servers](https://modelcontextprotocol.io/)

—

*This post demonstrates how to extend an existing project to support multiple testing frameworks while maintaining code quality and test coverage parity.*