🚀 Automating E2E Testing for AsyncAPI with Playwright - Proposal IDEA for GSOC 2025

[hxrshxz]

Why do we need this improvement?

🚀 Automating E2E Testing for the AsyncAPI Website with Playwright 🚀
🎯 1. What’s the Problem?
Let’s be real—testing the AsyncAPI website manually is a pain. Right now, if someone makes a change, we have to click through every page, check every link, and hope nothing breaks. And let’s not even talk about how different browsers can make things look wonky! 😅

Here’s what’s happening:

Stuff breaks silently: A tiny change can mess up the search bar or break a link, and we only find out when someone complains. 🐛

Testing takes forever: Contributors and maintainers spend hours manually checking the site instead of working on cool new features or content. ⏳

Browser headaches: The site might work perfectly in Chrome but look broken in Safari or Firefox. 🌐

Deployments feel scary: Without automated tests, pushing updates feels like rolling the dice. 🎲

This project is all about fixing these problems by automating UI testing for the AsyncAPI website using Playwright.

🛠️ 2. What Will I Do?
I’m going to build a testing framework that automatically checks the website for issues. Here’s the plan:

Test the basics:

Does the homepage load? ✅

Do all the links work? ✅

Can you search for stuff? ✅

Make sure it works everywhere:

Test on Chrome, Firefox, and Safari so the site works for everyone, no matter their browser. 🌍

Catch visual bugs:

Take screenshots and compare them to catch layout or styling issues. 🎨

Automate everything:

Set up tests to run automatically on every pull request and deployment. 🤖

Help others contribute:

Write clear docs so future contributors can add or update tests easily. 📚

🌟 3. Why Does This Matter?
Here’s how this helps AsyncAPI and its community:

Fewer bugs: Automated tests catch issues before they reach users, so the site stays reliable. 🛡️

Faster updates: Maintainers can deploy changes with confidence, knowing the site has been thoroughly tested. ⚡

Better for everyone: The site will work seamlessly across all browsers, so no one gets left out. 🌐

Easier for contributors: Newcomers can focus on building cool stuff instead of manually testing the site. 🧑‍💻

More trust: A reliable website means developers and organizations can rely on AsyncAPI as a trusted resource. 🤝

⏳ 4. Let’s Break It Down (9–12 Weeks)
Here’s how I’ll tackle this over 9–12 weeks:

Phase 1: Getting Started (Weeks 1–3)
Week 1: Set up Playwright and write basic tests for the homepage and docs.

Week 2: Test navigation (e.g., clicking links, loading pages) and search functionality.

Week 3: Test forms (e.g., newsletter signup, contact forms) to make sure they work.

Phase 2: Cross-Browser and Visual Testing (Weeks 4–6)
Week 4: Add tests for Chrome, Firefox, and Safari to catch browser-specific issues.

Week 5: Implement visual regression testing to catch layout or styling bugs.

Week 6: Optimize tests to run faster and fix any flaky tests.

Phase 3: Automation and Docs (Weeks 7–9)
Week 7: Integrate tests into GitHub Actions so they run automatically on every PR and deployment.

Week 8: Write clear, beginner-friendly docs to help others write and maintain tests.

Week 9: Do a final review, fix any issues, and hand off the testing framework to the community.

Phase 4: Maintenance and Expansion (Weeks 10–12)
Week 10: Monitor test results in CI/CD and fix any flaky tests.

Week 11: Add tests for more pages or features (e.g., blog, events page).

Week 12: Gather feedback from the community and make improvements.

💪 5. Why Am I the Right Person for This?
I’m excited about this project because:

I’ve done this before: I’ve built automated UI tests with Playwright, set up CI/CD pipelines, and debugged cross-browser issues. 🎯(Added a few playwright tests for JupyterLab recently using playwright check my JupyterLab fork)

I care about AsyncAPI: I’ve used the website and understand its importance to the community. 🛠️

I’m a problem-solver: I love digging into tricky issues and finding solutions. 🧩

I’ll keep you in the loop: I’ll share regular updates and work closely with maintainers to make sure I’m on the right track. 📢

I want to help the community: I’m excited to make the website more reliable so everyone can focus on building awesome things. 🌟

How will this change help?

Mentioned above

Screenshots

No response

How could it be implemented/designed?

Mentioned above

🚧 Breaking changes

No

👀 Have you checked for similar open issues?

• I checked and didn't find a similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue?

Yes I am willing to submit a PR!

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[vishvamsinh28]

@hxrshxz I have already discussed this idea with the maintainers, and we don’t see a big need for Snapshot UI testing at the moment

[akshatnema]

Hey @vishvamsinh28,
I discussed the Snapshot testing with you. We won't be doing any snapshot testing for the website, but we will probably write E2E tests for some critical workflows of website.

[vishvamsinh28]

Oh i thought you were talking about whole website 🫠