0

This is my code:

Link to my imports are here: https://github.com/django/django/blob/master/django/core/urlresolvers.py https://github.com/django/django/blob/master/django/contrib/auth/models.py https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/status.py https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/test.py

from django.core.urlresolvers import reverse
from django.contrib.auth.models import User
from rest_framework import status
from rest_framework.test import APITestCase

class UserTests(APITestCase):
    def test_create_user(self):
        """
        Ensure we can create a new user object.
        """
        url = reverse('user-list')
        data = {'username': 'a', 'password': 'a', 'email': 'a@hotmail.com'}
        # Post the data to the URL to create the object
        response = self.client.post(url, data, format='json')
        self.assertEqual(response.status_code, status.HTTP_201_CREATED)
        # Check the database to see if the object is created.
        # This check works.
        self.assertEqual(User.objects.count(), 1)

    def test_get_user(self):
        """
        Ensure we can get a list of user objects.
        """
        # This fails and returns an error
        self.assertEqual(User.objects.count(), 1)

When I run the test, it raises an error saying AssertionError: 0 != 1 because in the function test_get_user, the user created in test_create_user is not visible. Is there a way for me to get all the methods in a class to share the same database so that if I create a user in test_create_user, I can access it in the methods which come below it?

Edit: The reason I want them to share the same database for all the methods is because all of my test cases in the UserTests class will need a user created so I don't want to have to repeat the same code all the time even when it is tested in test_create_user.

I know I can use def setUp(self) but I'm doing a "create user" test in my first method so I want to be able to test if I can create it first before creating it in def setUp(self).

SilentDev
  • 20,997
  • 28
  • 111
  • 214
  • Please add `APITestCase` and your imports. – Sebastian Wozny Oct 24 '15 at 21:12
  • I think it is easier to create a separate test case to unittest user. It would basically test the code for creating users which could be used to prepopulate the DB in other test cases. – Ivan Oct 24 '15 at 21:23
  • @SebastianWozny I added the link to the GitHub source code (it's the default Django and DRF source code). – SilentDev Oct 24 '15 at 21:23
  • @Ivan Hm, what exactly do you mean? Are you saying that I create my own class to unittest `test_create_user` and then a separate class to unittest everything else which depends on creating a user (so that I can just create the user in the `def setUp(self)` method?). – SilentDev Oct 24 '15 at 21:25
  • Exactly, you shouldn't try to fit everything into one `TestCase`. – Ivan Oct 24 '15 at 21:27
  • @Ivan The thing is, I want to fit every testcase which tests the `User` model (GET User, CREATE User, PATCH User, PUT User and DELETE User) into one class since they are all related. – SilentDev Oct 24 '15 at 21:32
  • Then add utility methods to reuse object creation code as suggested in @DanielRoseman's comment. – Ivan Oct 24 '15 at 21:35

1 Answers1

4

You should set up your data explicitly in each test. Tests must not depend on each other.

Daniel Roseman
  • 588,541
  • 66
  • 880
  • 895
  • In my situation (see my edit at the bottom of my post) would you still recommend reusing the same part of the code (the part where I create the user) over and over in all my methods? Or is there a better way to do it? Note: I don't want to create the user in `def setUp(self)` because I want to be able to test if I can create a user first before creating it (the test is done in the first method - `def test_create_user(self)`. – SilentDev Oct 24 '15 at 21:23
  • No, you can just create the object directly via the ORM; no need to go via the post if you're not specifically testing that. But you can certainly put that into a separate utility method if you want. – Daniel Roseman Oct 24 '15 at 21:27