Hello everyone,
I am preparing a GSoC 2026 proposal for the project “Switch to Playwright tests for integration testing” and wanted to ask for feedback on a few design questions before finalizing the proposal.
My current idea is to introduce Playwright as an additional testing option alongside Selenium, rather than replacing Selenium immediately. This would allow gradual adoption, reduce migration risk, and keep the existing test workflow stable while the new approach is evaluated.
I would be grateful for feedback on the following points:
-
Would introducing Playwright alongside Selenium be a reasonable approach for Django initially, instead of treating it as a full replacement from the start?
-
Would it make sense to build Playwright support around
LiveServerTestCase(for example through aPlaywrightTestCase) so that it fits naturally into Django’s current browser-testing structure? -
For an initial migration scope, would it be better to focus on a small set of representative Selenium tests such as authentication, form submission, and navigation flows?
-
Are there specific browser-based tests in Django’s current test suite that would be good candidates for an initial Playwright migration?
-
From a maintainer perspective, what would be the most important success criteria for evaluating whether Playwright integration is useful enough for broader adoption?
-
Are there any concerns I should keep in mind regarding CI setup, test maintainability, or long-term coexistence between Selenium and Playwright during an incremental adoption phase?
My goal is to keep the approach simple, backward-compatible, and aligned with Django’s current testing patterns.
For context, I have been contributing to Django-related projects and am currently shaping my proposal around test reliability, CI compatibility, and contributor usability.
Thank you for your time — I would really appreciate any guidance or suggestions.
— Keha Chandrakar
GitHub: https://github.com/kehach07