2026-06-18 Frontend Working Group Meeting Notes

 Time, location

• Time: 15:00 UTC

• Location: https://meet.google.com/wxe-myxy-uei

 Agenda

📝Notes

• BTR is asking for help with testing: Brian took care of a few

• Brian is off next week, is taking care of things so nothing depends on him for the release

• Jesse asks: new repo for playwright-e2e tests?

• Adolfo asks: -alpha suffix for frontend-base development package?

 Decisions

1. We’re going to keep using the -alpha suffix for the development package of frontend-base (and related packages)

 Action items

Previous Action Items

🎥Recording

• Video: https://drive.google.com/file/d/1NAu-AxlHaesn9_6YGcwBTfm7DO0xW3sy/view?usp=drive_link

• Transcript: https://drive.google.com/file/d/1a2rbiHY8PclNjHQyTIUOdHXh_TfdHGA_G0FJmucQOwE/view?usp=drive_link

 Participants

Adolfo Brandes, Brian Smith, Diana Villalvazo Salas, Jesse Stewart-WGU

🤖 Summary

Main themes

The meeting focused primarily on BTR release testing, especially how to reduce the manual testing burden through automation. The group also discussed where end-to-end tests should live, whether to use Cypress or Playwright, and the upcoming frontend-base 1.0 release branching/versioning plan.

Key discussion points

BTR testing is currently a release bottleneck

Adolfo noted that BTR is asking for help with testing and that testing is currently holding up the release. Brian had already completed some testing, including instructor dashboard testing, and said he could do more before being out the following week.

Brian also confirmed that several important items had landed, including a release-blocking sidebar fix and its backport. He had also merged a Discussions-related slot change, but had not yet backported it.

Discussions header slot backport

The group agreed that the missing header slot in one microfrontend is closer to a bug than a feature, because it prevents replacing the full header consistently.

Decision: It is not a release blocker, but it should be backported.

Action item: Brian will create the backport for the Discussions slot/header change.

Automated testing strategy

Jesse discussed being asked by Peter to help write automated tests. He raised several concerns:

• What parts of BTR testing are worth automating?

• How should test data be created and cleaned up?

• Where should automated tests live so they stay visible and maintained?

• Who owns updating tests when product behavior changes?

• How can automation avoid becoming more release-blocking tech debt?

Adolfo agreed that data setup is probably the hardest part. He emphasized that even partial automation would be valuable if it makes the BTR process cheaper and faster.

The group leaned toward an incremental goal: do not start by requiring all tests to run in CI for every PR. Instead, focus first on making current BTR testing easier to run, possibly by spinning up a fresh known-good environment, running automated checks, and reporting results.

Ownership and maintenance of tests

Brian asked how the current manual testing spreadsheet is updated. Adolfo explained that Chelsea, with involvement from product/BTR/PTR processes, currently reviews and updates test sheets for each release. New features are considered and test cases are added manually.

The group agreed this is not ideal. Ideally, PRs or product changes would include a signal that tests need to be updated, but there is currently no mechanism for that.

Brian noted that product proposal acceptance criteria may be a starting point for defining tests, but Adolfo pointed out that not all behavior changes come through formal product proposals.

Test location and architecture

Jesse proposed segmenting tests by microfrontend so each MFE owns its own tests. That would allow relevant tests to run only when a specific microfrontend changes, rather than running the full suite.

Potential benefits:

• Clearer test ownership

• More visibility for developers changing the code

• Smaller test runs per PR

• Easier maintenance over time

Open concerns:

• Backend environment requirements

• Test data setup and teardown

• Mocking sessions/login

• Keeping cloud infrastructure current

• Handling release branches and backports

Test data and infrastructure

Jesse said some test data could be created programmatically. He has already used Tutor to create users, certificates, and other test fixtures, but more Tutor-side utility work would likely be needed.

Brian raised concerns about CI environments that depend on a shared backend: stale data, cleanup responsibility, backend version drift, and failures caused by unrelated infrastructure issues.

Adolfo suggested reframing the first goal as making BTR release tests cheaper and faster, rather than immediately solving full PR-level CI. One possible model would be a button or command that creates a fresh environment, runs automated tests, and produces a report.

Cypress vs. Playwright

The group discussed the existing Cypress end-to-end test repository and the possibility of creating a new Playwright-based repo.

Jesse has experience with both Cypress and Playwright and said Playwright is easier to work with, more modern ergonomically, and better for screenshots and browser/headless testing workflows. However, he cautioned that if the existing Cypress test framework is already useful and actively maintained, it may be better to build on that rather than duplicate effort.

Brian found a Slack thread indicating that others had discussed creating a general Open edX E2E tests repo. Max from Raccoon Gang had apparently said that a new framework should go in a new repo, while the existing Cypress repo can continue running existing tests.

Action item: Jesse will review and comment on the relevant Slack thread, especially with his perspective on Cypress vs. Playwright.

Action item: Adolfo will raise the topic at Axim Engineering Standup, including whether a Playwright E2E tests repo should be created and how it should be named.

Repository naming

The group discussed possible names such as playwright-end-to-end-tests, but noted that some people prefer avoiding framework names in repo titles.

No final repository name was chosen.

Jesse’s availability

Jesse said he is currently working on WGU theming tasks and his longer-term availability is uncertain, especially beyond the next several weeks. The group acknowledged that even a small contribution, such as commenting on direction and tooling, would be valuable.

frontend-base 1.0 release plan

Adolfo brought up the upcoming work to issue 1.0 versions of frontend-base packages. Diana is now a core contributor for frontend-base, which helps because Brian will be away.

The proposed model is:

• Create a 1.0 branch for stable releases.

• Keep main as the development branch.

• Continue publishing prerelease versions from main.

The group discussed what prerelease tag should be used after 1.0. Options included alpha, next, main, or similar.

Decision: Keep using alpha unless there are strong objections.

So the expected future versioning pattern is something like:

• Stable branch: 1.x

• Main branch prerelease: 2.0.0-alpha

The group acknowledged that backports will need to be handled case by case, especially once breaking changes land on main.

Decisions

1. The Discussions header/slot change should be backported, though it is not a release blocker.

2. Initial automated testing work should focus on making BTR testing cheaper and faster, not necessarily on full CI integration for every PR.

3. The group is interested in Playwright, but wants to understand the state and value of the existing Cypress tests before duplicating effort.

4. For frontend-base, the group will proceed with a 1.0 branch and keep prereleases from main using the alpha tag.

Action items

Open questions

• Should Open edX create a new E2E testing repo, and should it be framework-specific?

• Should the community continue investing in Cypress, migrate to Playwright, or support both temporarily?

• Where should automated tests live: central repo, per-MFE repo, or a hybrid model?

• Who is responsible for updating tests when product behavior changes?

• How should automated tests create and clean up data reliably?

• What infrastructure is needed to run automated BTR tests against fresh environments?

• How should release branches and backports interact with automated test suites?