Hello Django community,
I’m Harshitha, a software engineering student focused on backend and cloud-native application development. I enjoy working on systems that are scalable, reliable, and production-ready — especially where testing, performance, and developer experience intersect.
Over the past year, I’ve built and deployed API-driven applications and ML-powered systems on AWS serverless infrastructure, which sparked my interest in how strong frameworks like Django maintain stability at scale. That curiosity is what brings me here.
For GSoC 2026, I’m particularly interested in contributing to the Playwright integration testing project, as I’m passionate about improving testing reliability and modernizing developer workflows. I’d love to understand how Django currently handles integration testing and where I can begin contributing — even with small improvements or beginner issues.
My goal is not just to submit a proposal, but to become a meaningful contributor to Django’s ecosystem and learn from the community along the way.
Looking forward to collaborating and learning with you all.
Thank you!
1 Like
Hello everyone,
While exploring Django’s Selenium-based browser testing infrastructure, I noticed that browser drivers are dynamically imported in tests/selenium.py. I’ve been experimenting with a small prototype using Playwright with Django’s LiveServerTestCase to understand how browser automation could work with Django tests.
I’m considering proposing a GSoC project to introduce Playwright support alongside Selenium through a browser abstraction layer. Before drafting the full proposal, I wanted to ask for feedback on the design direction.Would it be better to extend the existing SeleniumTestCase, or would introducing a more generic browser driver interface be a better approach for supporting multiple backends like Selenium and Playwright?
I believe that playwright can already be integrated without django official support, and I dont think adding dedicated feature for it would be efficient. but what could be efficient is enhancing testing environemnt of django.
Thanks for the insight! That makes sense.
If Playwright can already be used independently in Django tests, then introducing direct framework support might not add significant value.Do you think focusing on improving Django’s browser testing infrastructure (for example improving SeleniumTestCase, test configuration, or test performance) could be a better direction for a GSoC project?I would love to explore areas where Django’s current testing setup could be improved and contribute there.
Improving something is always a good approach,but could you tell an example where do you think testing env can be improved, or have you come across a problem in testing?, If you can explain that i think it would be good for your proposal
Thank you for the suggestion!
While exploring Django’s Selenium-based testing setup, I noticed that configuring browser drivers and maintaining cross-browser compatibility can sometimes be cumbersome, especially for contributors who are new to the testing framework.For example, setting up and managing different drivers can add additional complexity to the testing environment. Modern browser automation tools such as Playwright simplify this process by automatically managing browsers and providing faster and more reliable test execution.
One possible improvement could be introducing a more flexible browser testing abstraction that makes it easier to configure and run browser tests, while still supporting tools like Selenium or other modern automation frameworks.
I’m still exploring Django’s testing infrastructure and would be interested in identifying areas where the developer testing experience could be improved.
1 Like