When you build a testing framework, the actual test execution logic is only half the work. The other half is making it installable, configurable, and ready for someone else's repository.
I just published the Phase 1 milestone for Praman, an open-source QA engine for Python. The repo is live on GitHub. Here is what it took to get the core framework packaged and running.
The first challenge wasn't writing more browser-automation code. It was building the wheel.
Building a source distribution and a wheel forces you to look at your code from the perspective of a client. I had to verify the package metadata, ensure that Pytest was declared correctly, and make sure the plugin auto-registration worked. Praman uses a pytest11 entry point, which means when a client installs the wheel, the praman_page fixture is available immediately. They don't have to copy any conftest.py files.
The only way to trust this is to test it in isolation. I installed the wheel in a fresh Python environment and ran a smoke test against it. It passed. That single external test proves more than a hundred local tests, because it confirms the packaging actually works.
The test suite is currently at 476 tests passing. One of the tests covers the configuration precedence we talked about in the last article. Another covers the pytest plugin discovery. They run in seconds, which means they can go into a CI pipeline on every commit without slowing things down. The GitHub Actions workflow is already set up and passing.
A QA framework is only as good as its documentation.
I spent time writing a CLIENT_SETUP.md guide and a full README. The README needed to explain the exact difference between the standard configuration pipeline (YAML first, then environment variables, then CLI arguments) and the pytest fixture configuration (which uses two specific environment variables to load the YAML file). Those are two separate concerns, and if the documentation blurs them, the client will guess wrong.
I also added the MIT license and cleaned up the repository structure. The framework folder holds the core code, the tests folder holds the verification suite, and the pyproject.toml declares the build dependencies.
This is not a finished platform. It is a foundation. The roadmap includes API and UI automation, CI/CD integrations, and AI-assisted test analysis. But none of those matter if the base package doesn't install cleanly.
If you want to look at the code or try the wheel, the repository is public. The feedback loop on packaging is what makes the next phase possible.
Top comments (0)