This Django API test platform documents its own breakage in the version history

The README says the current version does not work

Most project READMEs describe what a project does. This one describes what broke, and it is the first thing worth reading.

The v2.0 entry states that the interface code was refactored, that a deserialisation approach was introduced and that the interfaces were changed to class-based. It then says that because a large amount of backend interface code changed, the front end was not updated, that front end calls to the interfaces will now produce many problems, and that the platform is currently unavailable pending a later update.

That is a project saying its own web tier does not match its API tier. The repository is not archived and the last push was on 2026-04-07, so someone is still committing, but the README offers no version that claims to fix v2.0. The most recent listed version is v2.3, which is described only as introducing Docker deployment.

The project description adds a second warning: the old platform has moved to the `master_old` branch. So there are two codebases here, and the one on the default branch `master` is the one with a known mismatch.

There is a third thing at the top of the README: the server has expired and renewal is not planned. A demo address is listed with a request not to delete existing data. So there is no live instance to evaluate against either.

What the platform was built to do

The feature walkthrough at the end of the README is numbered and screenshot by screenshot, and it is the best description of the intended product in the document.

There is no registration and no forgotten password flow. Accounts are created and assigned from the admin backend, which tells you the model: this is an internal tool for a team, not a self-service product.

Only interface testing is open at this stage, so the top level is a project list supporting add, delete, query, update and batch delete. Clicking a project name opens an overview. From there the HOST configuration page provides add, delete, update, query and batch modification of host variables that act as globals when automated tests execute.

The API page is the interesting part. It allows a quick test similar to Postman, and it manages interface groups for organising APIs by module and project interfaces with add, edit and delete. When adding an API, the README notes only two body formats are supported: raw data and form-data. There is also an interface detail view for testing, editing, deleting and looking at the interface's change history, and a downloadable interface documentation template.

Automated testing is the fourth area: case grouping, full CRUD on cases, and scheduled tasks. Under a case you attach existing APIs from the API module, choose an environment to test against, download the test report and set a schedule. Cases added this way default to no verification.

Project members are display-only, with add and delete handled from the admin backend, and the project activity view shows changes from the last three days. Generated reports keep the ten most recent results.

Stack: Django REST framework, Vue, Element UI, and a lot of services

The stack statement is short. The interfaces are written with Django REST framework, and the front end uses Vue with Element UI. The README also names the versions it was written against: Python 3.6.3 and Django 2.0.2.

Those two version numbers date the project precisely. A Django 2.0.2 codebase will not run on a modern Django without work, and Python 3.6 has been unsupported for years.

The current branch has grown well past those two components. The top level of the tree contains `AutoTest_New/`, `api_test/`, `backend/`, `api_automation_test/`, `UserInfo/`, `Config/`, `RootDirectory.py` and `replace_celery.py`. There is an `allure-2.7.0/` directory, a bundled Allure reporting distribution, and `case_logs/` and `logs/` for output.

The Compose file names five services: `api_automation_test`, `redis`, `nginx`, `rabbitmq` and `mysql`. The application service depends on redis, rabbitmq and mysql, and its command starts uWSGI from `UwsgiScript/uwsgi.ini`, then supervisord, then holds the container open. Redis runs the `redis:alpine` image, nginx publishes port 5555, rabbitmq runs as root, and every service rotates its json-file logs at 12 MB with five files kept.

So Celery and Redis are in play for the scheduled tests, RabbitMQ is the broker, MySQL the store, and nginx fronts the app. That is a five-service deployment for what is fundamentally an HTTP request runner, and it is the reason the Docker route exists at all.

A local run is eleven steps, and step four has a root password in it

The setup section is a numbered walkthrough, and it is specific enough to follow, which is more than many abandoned projects offer.

Dependencies come from requirements.txt, plus one package installed from a GitHub tarball:

pip install -r requirements.txt
pip install https://github.com/darklow/django-suit/tarball/v2

Then the database connection is edited in `api_automation_test/settings.py`. The example block in the README ships with a root user and a literal password:

DATABASES = {
    'default': {
        # 'ENGINE': 'django.db.backends.sqlite3',
        # 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
   'ENGINE':'django.db.backends.mysql',     # 数据库类型，mysql
   'NAME':'api_test',                      #  database名
   'USER':'root',                          # 登录用户
   'PASSWORD':'123456',                    #  登录用户名
   'HOST':'127.0.0.1',                     # 数据库地址
   'PORT':'3306'                           # 数据库端口
    }
}

That commented-out SQLite alternative is worth noticing. It is the fastest way to look at the model layer without installing MySQL, and it is already in the file.

The remaining steps are the standard Django sequence: `makemigrations` then `migrate` to build the tables, `createsuperuser` for the admin login, `npm install` inside `frontend/` and `npm run build` to package the front end. The service is then started with `python manage.py runserver 0.0.0.0:8000`, after which the README points at `http://127.0.0.1:8000/login` for login and `http://127.0.0.1:8000/admin` for the backend.

Nothing in that sequence works end to end on v2.0, because the front end does not match the back end. What you would be building is a working backend with a broken client.

Docker on CentOS 7 Python 3.6, with a pinned Chinese pip index

The v2.3 entry introduces Docker deployment, and the Dockerfile is short enough to read in full.

FROM centos/python-36-centos7:latest
COPY ./requirements.txt /api_automation_test/
USER root
WORKDIR /api_automation_test
RUN pip install -i https://pypi.tuna.tsinghua.edu.cn/simple --no-cache-dir --upgrade pip\
    && pip install --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple --no-cache-dir -r /api_automation_test/requirements.txt --default-timeout=200 --ignore-installed\
    && yum -y install java-1.8.0-openjdk \
    && java -version
COPY ./replace_celery.py /opt/app-root/lib/python3.6/site-packages/djcelery/management/commands/celery.py
CMD [ "sh", "-c", "while true; do sleep 1; done"]

Three things in there deserve attention.

The base image is `centos/python-36-centos7:latest`. Python 3.6 on CentOS 7. The README justifies the container route partly by saying that because the base image is CentOS, scheduled tasks still work on Windows, which is a real problem that Docker solves here.

The pip index is hardcoded to a Tsinghua mirror, twice, with `--ignore-installed` and a 200 second default timeout. That is a reasonable choice for a China-based install and a poor one anywhere else, since it makes every dependency resolution go through one mirror.

And the final COPY overwrites Celery's own management command inside site-packages with a local `replace_celery.py`. That is a monkey patch baked into the image. Whatever incompatibility prompted it is patched at the filesystem level rather than fixed, so anyone debugging the scheduled task inside the container needs to know the file in `djcelery/management/commands/celery.py` is not the one that shipped with Celery.

A Java 8 runtime is also installed in the image.

What the requirements list reveals about the intended feature set

requirements.txt is unpinned for the framework itself. `Django` and `djangorestframework` appear with no version, while most other entries either pin or leave a name. That means a fresh install resolves to whatever is current for the interpreter, which is the single biggest obstacle to reproducing this environment.

The rest of the list is a map of what the project actually does rather than what the README claims.

For interface definition and execution: `requests` and `jsonpath`, which together suggest assertions against response bodies by path.

For reports: `allure-pytest` with `pytest`, plus `pytest-rerunfailures` and `pytest-repeat`. Allure is the reporting format, and the rerun and repeat plugins are how a flaky suite is handled rather than failed on.

For the platform itself: `django-rest-swagger` and `coreapi`, which is the v2.1.1 feature that added a Swagger UI at `127.0.0.1:8000/docs`; `django-celery` with `celery`, `celery-with-redis`, `redis`, `channels`, `channels_redis`, `asgi_redis` and `asgiref` for scheduled and async work; `django-redis` for caching.

For data: `PyMySQL`, `django-import-export` and `xlrd`, which together suggest Excel import for test cases, and `TestLink-API-Python-client`, which points at reporting results into an external TestLink instance rather than keeping everything local.

For the admin: `django-simpleui` replaces the default Django admin theme, and `django-formtools`, `django-cors-headers`, `djangorestframework-stubs` and `PyYAML` fill out the surrounding tooling. `uWSGI` and `supervisor` are the process management pair the Compose file uses.

The v2.1 entry also adds a mock server: the API management module can start and stop mock, and once started, visiting `http://127.0.0.1:8000/mock/` plus a real URL returns mock data. That is the one genuinely useful capability for a test platform and it does not depend on the front end.

Editorial conclusion

Adopt this platform only if you want to extend it rather than run it, because the README states plainly that the v2.0 refactor changed the interface layer to class-based views, that the front end was not updated to match, that calls from the browser fail in many places and that the platform is therefore currently unusable. It is not a candidate for a team that needs working API regression tests this quarter. Before spending a day on it, check whether the older platform on the `master_old` branch suits you better, since the project description points there for the previous version, and budget for a dependency rebuild if you do try v2.3: the Dockerfile is based on `centos/python-36-centos7:latest` and the requirements list unpinned Django and djangorestframework, so reproducing the environment with `docker-compose up` may be difficult.

Frequently asked questions

Official sources

1. githublitao/api_automation_test on GitHub
2. Issues
3. License: MIT
4. README