DEV.co
Open-Source Testing · revsys

django-test-plus

django-test-plus is a Python library that extends Django's built-in TestCase with convenience methods to reduce boilerplate when writing tests. It provides helpers for URL reversing, HTTP requests, response assertion, and context checking, supporting Django 4.2 through 6.0 and Python 3.10–3.14.

Source: GitHub — github.com/revsys/django-test-plus
633
GitHub stars
63
Forks
Python
Primary language
BSD-3-Clause
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryrevsys/django-test-plus
Ownerrevsys
Primary languagePython
LicenseBSD-3-Clause — OSI-approved
Stars633
Forks63
Open issues10
Latest releaseUnknown
Last updated2026-01-02
Sourcehttps://github.com/revsys/django-test-plus

What django-test-plus is

A mixin-based testing utility that wraps Django's TestClient and assertion framework, offering fluent methods for common patterns (reverse(), get(), post(), assert_http_###_*()) and pytest fixtures (tp, tp_api). The library stores response state (last_response, context) to streamline multi-step test assertions.

Quickstart

Get the django-test-plus source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/revsys/django-test-plus.gitcd django-test-plus# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Reducing view test boilerplate

Teams writing many view tests benefit from the fluent get()/post() interface and automatic context storage, cutting down repetitive reverse() and assertEqual(response.status_code, ###) calls.

pytest migration or mixed test suites

Projects transitioning to pytest or maintaining both unittest and pytest can use the tp fixture to apply the same assertion helpers across frameworks without rewriting test logic.

API testing with DRF

The tp_api fixture provides an APIClient-based TestCase for Django REST Framework projects, bundling HTTP verb helpers with response assertion shortcuts.

Implementation considerations

  • Inherit from test_plus.test.TestCase or create a project-level base class wrapping it to enable custom helper methods across your test suite.
  • Methods like get(url_name, data={...}) assume named URLs; verify your Django URL patterns use the name= kwarg consistently.
  • The context attribute and last_response storage are set by get/post/put/patch/delete/head/options/trace calls; calling other methods may lose that state.
  • pytest fixture usage (tp, tp_api) requires pytest + pytest-django; ensure both are in your dev dependencies if switching from unittest.
  • Status assertion methods (assert_http_200_ok, etc.) require no response argument if called immediately after a get/post; passing an explicit response object is always safe.

When to avoid it — and what to weigh

  • Complex integration testing — If tests require advanced mocking, transaction management, or multi-service orchestration, django-test-plus's lightweight assertion helpers won't address those needs; use pytest + factory_boy or dedicated integration frameworks.
  • No Django dependency — The library is tightly coupled to Django; non-Django Python projects will gain no value and should use standard unittest or pytest assertions instead.
  • Minimal test volume — Small codebases with only a handful of tests may not justify the dependency; plain Django TestCase is often sufficient for trivial test suites.
  • Custom test framework or async testing — If your team uses a proprietary test harness or requires advanced async/await patterns, django-test-plus's synchronous TestCase inheritance may not fit.

License & commercial use

Licensed under BSD-3-Clause, a permissive OSI-approved license allowing modification, redistribution, and commercial use with minimal restrictions (retain license text and copyright notice).

BSD-3-Clause is a permissive license compatible with commercial projects. Ensure you retain the license text and copyright notice in distributions; no explicit permission request or fee required. Consult internal legal review if bundling with proprietary code.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

django-test-plus is a testing utility and does not handle sensitive data in production. In tests, use generated or fixture data, not real credentials. The library itself has no known CVEs in the data, but always pin versions in dev requirements. Review dependencies (Django, pytest) separately for security advisories.

Alternatives to consider

pytest + pytest-django + factory_boy

Offers more granular control, functional fixtures, and object factories; better for complex multi-step tests. No inheritance required; pure pytest functions can co-exist with Django TestCase.

Django's built-in TestCase + unittest

No external dependencies; sufficient for small-to-medium test suites. Requires more boilerplate (manual reverse, explicit assertions) but avoids the learning curve and maintenance burden of a third-party library.

hypothesis + Django property-based testing

For model validation and edge-case testing; generates test data automatically. Complements, not replaces, django-test-plus; useful when you need exhaustive input space coverage.

Software development agency

Build on django-test-plus with DEV.co software developers

django-test-plus cuts down test boilerplate with convenient helpers. Integrate it into your Django project today—or discuss custom testing strategies with our team.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

django-test-plus FAQ

Do I have to use django-test-plus for the entire project?
No. You can mix TestCase and test_plus.test.TestCase in the same codebase. Inherit from whichever is more convenient per test file.
Is pytest required?
No. django-test-plus works as a standard Django TestCase mixin. pytest is optional; use tp and tp_api fixtures only if you want pytest support.
Does it work with Django REST Framework?
Yes, via the tp_api fixture for pytest or by inheriting TestCase and accessing self.client.post/put/patch. No built-in REST serialization assertion helpers, so you still verify response JSON manually.
What if my project uses async views?
django-test-plus is synchronous. Use Django 3.1+'s AsyncClient directly or pytest-asyncio + pytest-django for async test support; django-test-plus helpers will not wrap async code.

Custom software development services

DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If django-test-plus is part of your open-source testing roadmap, our team can implement, customize, migrate, and maintain it.

Simplify Your Django Tests

django-test-plus cuts down test boilerplate with convenient helpers. Integrate it into your Django project today—or discuss custom testing strategies with our team.