Not answering any of these questions (sorry) but strong +1 on adding end-to-end (E2E) tests. This will significantly make our UI more robust but also will speed up some of our work. An example is front-end dependency upgrades by dependabot. Today we have no way of knowing whether these PRs break the UI, in order to merge these PRs we need to compile the front-end assets and test manually whether the UI work. Having end-to-end tests on the front-end and making them run in the CI would speed up this very example (on top of increasing code robustness, increase our confidence etc).
On 2025/09/23 11:03:40 Rahul Vats wrote: > Hi all, > > With Airflow 3.0, the UI has undergone a complete revamp, and new changes > are naturally more prone to regressions. We've already seen more UI > regressions that are hard to catch with our current limited test coverage. > Manual testing is also challenging given the wide variety of workflows and > screens in the UI. > > Currently, the Airflow UI has a few unit tests using Vitest and React > Testing Library, but coverage is quite limited — only about 4 test files > covering major pages like DagsList and TaskInstance. Many critical > pages (Connections, > Variables, Pools, Dashboard, etc.) have no test coverage at all. > > I’m exploring a two-pronged approach to improve UI testing: > > 1. > > Expand unit test coverage for individual components and pages > > 2. > > Add end-to-end (E2E) tests using Playwright for complete user workflows > > > This would give us both component-level safety and full user-journey > testing across browsers, helping catch regressions early. > > A few questions: > > - > > Should we prioritize expanding unit test coverage first, or work on unit > and E2E tests in parallel? > > - > > For E2E testing, is Playwright a good choice, or are there other > preferred tools we should explore? > > - > > If Playwright, should we use TypeScript or Python as language for tests? > > - > > Any other suggestions to strengthen our UI testing strategy? > > > I’d love to hear your thoughts on whether this would be valuable for the > project before diving into implementation details. > > Regards, > Rahul Vats > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
