Top AI Repos — open-source AI, indexed and scored
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Top AI Repos tracks AI repositories on GitHub and answers two different questions about each one: is it moving right now, and would you bet a product on it.
Useful additions to Django's default TestCase
| Date | Stars |
|---|---|
| 2026-07-24 | 632 |
| 2026-07-25 | 632 |
| 2026-07-28 | 632 |
| 2026-07-30 | 632 |
| 2026-08-06 | 632 |
Today
— stars today
This week
— stars this week
This month
— stars this month
Momentum
0.0
growth rate 0.00%/day
# django-test-plus
Useful additions to Django's default TestCase from [REVSYS](https://www.revsys.com/)
[](https://pypi.org/project/django-test-plus/)
[](https://github.com/revsys/django-test-plus/actions/workflows/actions.yml)
## Rationale
Let's face it, writing tests isn't always fun. Part of the reason for
that is all of the boilerplate you end up writing. django-test-plus is
an attempt to cut down on some of that when writing Django tests. We
guarantee it will increase the time before you get carpal tunnel by at
least 3 weeks!
If you would like to get started testing your Django apps or improve how your
team is testing we offer [TestStart](https://www.revsys.com/teststart/)
to help your team dramatically improve your productivity.
## Support
- Python 3.10, 3.11, 3.12, 3.13, and 3.14.
- Django 4.2 LTS, 5.1, 5.2 LTS, and 6.0.
## Documentation
Full documentation is available at http://django-test-plus.readthedocs.org
## Installation
```shell
$ pip install django-test-plus
```
## Usage
To use django-test-plus, have your tests inherit from test_plus.test.TestCase rather than the normal django.test.TestCase::
```python
from test_plus.test import TestCase
class MyViewTests(TestCase):
...
```
This is sufficient to get things rolling, but you are encouraged to
create *your own* sub-classes for your projects. This will allow you
to add your own project-specific helper methods.
For example, if you have a django project named 'myproject', you might
create the following in `myproject/test.py`:
```python
from test_plus.test import TestCase as PlusTestCase
class TestCase(PlusTestCase):
pass
```
And then in your tests use:
```python
from myproject.test import TestCase
class MyViewTests(TestCase):
...
```
This import, which is similar to the way you would import Django's TestCase,
is also valid:
```python
from test_plus import TestCase
```
## pytest Usage
You can get a TestCase like object as a pytest fixture now by asking for `tp`. All of the methods below would then work in pytest functions. For
example:
```python
def test_url_reverse(tp):
expected_url = '/api/'
reversed_url = tp.reverse('api')
assert expected_url == reversed_url
```
The `tp_api` fixture will provide a `TestCase` that uses django-rest-framework's `APIClient()`:
```python
def test_url_reverse(tp_api):
response = tp_api.client.post("myapi", format="json")
assert response.status_code == 200
```
## Methods
### `reverse(url_name, *args, **kwargs)`
When testing views you often find yourself needing to reverse the URL's name. With django-test-plus there is no need for the `from django.core.urlresolvers import reverse` boilerplate. Instead, use:
```python
def test_something(self):
url = self.reverse('my-url-name')
slug_url = self.reverse('name-takes-a-slug', slug='my-slug')
pk_url = self.reverse('name-takes-a-pk', pk=12)
```
As you can see our reverse also passes along any args or kwargs you need
to pass in.
## `get(url_name, follow=True, *args, **kwargs)`
Another thing you do often is HTTP get urls. Our `get()` method
assumes you are passing in a named URL with any args or kwargs necessary
to reverse the url_name.
If needed, place kwargs for `TestClient.get()` in an 'extra' dictionary.:
```python
def test_get_named_url(self):
response = self.get('my-url-name')
# Get XML data via AJAX request
xml_response = self.get(
'my-url-name',
extra={'HTTP_X_REQUESTED_WITH': 'XMLHttpRequest'})
```
When using this get method two other things happen for you: we store the
last response in `self.last_response` and the response's Context in `self.context`.
So instead of:
```python
def test_default_django(self):
response = self.client.get(reverse('my-url-name'))
self.assertTrue('foo' in response.context)
self.asseExcerpt of 18,856 characters
Read on GitHub
210
195
Flavio Curella · @minted
46
27
25
21
9
9
7
7
7
4
4
3
3
3
2
2
2
2
Would you bet a product on this? Bounded 0–100 and slow moving.
matched fp:fb25d5a32c9472f5, topic:testing