Every tester knows the drill: a requirement document lands, and you spend the next few days manually translating it into test case tables — preconditions, steps, expected results. Then the API/UI automation scripts you wrote last quarter break because one page changed.
We got tired of it, so we built WHartTest and open-sourced it: an AI-driven test automation platform that turns requirement documents into executable test cases — and helps fix them when they fail.
What it does
Functional test case generation. Upload requirement documents (with an online editor built in). AI generates complete cases — preconditions, steps, expected results — grounded in your project knowledge base. Cases are managed in list or mindmap view, with drag & drop, P0–P3 tags, and export to PNG/JSON.
API automation. From an API definition, AI generates request steps, assertions, variable extraction, and pre/post scripts. When a run fails, AI reads the logs and responses to locate the problem and proposes fixes.
UI automation. AI generates page operation steps and element locators. Runs capture logs, screenshots, video, and Playwright traces. When a locator breaks or an assertion fails, AI analyzes the evidence and suggests repairs. Since v2.8.0 there is a frame-stream Playwright recorder: you record interactively and create elements/steps as you go — no more hand-writing scripts.
Under the hood
- Django 5.2 + DRF backend, Vue frontend, monorepo architecture
- LangChain/LangGraph orchestration for multi-turn reasoning
- RAG knowledge base: document chunking, vectorization, reranking
- MCP (Model Context Protocol) tool calling
- A Skills system: WHart-SkillHub (new in v2.8.1) is an open skill center — install skills with natural language or one CLI command; Skills management is natively integrated in both desktop and web clients
Other recent highlights: smart dual-mode execution (script / pure-AI / dual), AI self-healing failure diagnosis, multi-format API doc import & export (OpenAPI, Swagger, Postman, HAR, curl, Apifox, YApi...), and operation audit logs.
Facts & links
- GitHub: https://github.com/MGdaasLab/WHartTest (1.1k+ stars, 940+ commits)
- Website: https://wharttest.mgdaas.com/
- Docs: https://docs.wharttest.mgdaas.com/
- Self-hostable; strong security note: the Skills module has elevated system permissions — deploy in trusted/internal networks
- License: Apache 2.0 with additional conditions (see the LICENSE file; versions up to v2.6.0 were MIT)
We'd love feedback from QA engineers: how is AI-generated test case generation working out in your teams? What would you want next?
Top comments (2)
@alexcodebytes The heal has to be narrower than the locator. If the element's role and accessible name still match, healing is fine. If the match falls back to a different button, the run should fail, or at least log the heal as a finding. A deleted submit button is exactly the case where a silent pass hides the bug.
The self-healing Playwright locators are the holy grail for QA, but I'm curious how the AI distinguishes between a broken locator and a genuine UI bug? If a developer accidentally deletes a submit button, the AI might just 'heal' the test by clicking on something else instead of failing the run.