Как проверить представление, которое создает новую команду (сущность) в базе данных?

Question

Мне нужно протестировать мой текущий проект, и я наткнулся на контрольно-пропускной пункт. Я нахожусь на 85% -ом покрытии, и мне нужно закончить этот тест, чтобы go дальше. По сути, мне нужно проверить, что мой взгляд способен создать новую команду в моей базе данных. Командная модель вложена в организацию в форме внешнего ключа.

models.py -

class Organization(models.Model):
    orgname = models.CharField(max_length = 100, blank=True)

    def __str__(self):
        return str(self.orgname)

class Team(models.Model):
    teamID = models.AutoField(primary_key=True)
    teamName = models.CharField(max_length = 100, blank=True)
    org = models.ForeignKey(Organization, on_delete=models.CASCADE)

    def __str__(self):
        return str(self.teamName)

views_admin.py -

@csrf_exempt
def newTeam(request):
    if request.method == 'POST':
    param = json.loads(request.body)
    orgname = param.get('org')
    team = param.get('team')
    org = Organization.objects.get(orgname = orgname)
    print(org)
    Team.objects.create(teamName=team, org=org)
    return JsonResponse({'status':200})

urls.py -

path('ajax/newTeam/', views_admin.newTeam, name='ajax_newTeam'),

Я пробовал это так далеко:

def test_newTeam(self):
    params = {'orgname': REVCYCSCH, 'teamName': 'BLR Scheduling Eng'}
    response = self.client.post(path = '/ajax/newTeam/', data = params, content_type = 'application/json')
    self.assertEqual(response.status_code, 200)  

Но я получаю эту ошибку -

Answer 1

Как упоминает lalithkumar, то, что вы написали, на самом деле является скорее интеграционным тестом, чем надлежащим модульным тестом - правильный модульный тест напрямую вызовет функцию представления с объектом request ручной работы и mock моделью. слой.

Теперь обратите внимание, что это само по себе неплохо - интеграционные тесты тоже имеют свое применение, и в этом случае ваш тест выявляет недостаток в вашем коде представления и вашем API-интерфейсе c: вы не обработка случая, когда организация не существует - фактически, вы вообще не обрабатываете ошибки.

IOW, вы делаете хотите сохранить этот тест - и, возможно, добавить другие тесты, отправляющие другие недействительные данные - и проверить, что вы получаете код состояния 4XX (4xx => неверный запрос) и некоторые подробности об ошибках в вашем json.

Кроме того, для номинального случая (команда успешно создана) вы можете вместо этого вернуть 201 Создано (как статус ответа ). , не в самой json!), Со ссылкой на вновь созданную команду в содержимом json.

Примечание: конечно, если вы не высмеиваете слой модели, который у вас есть создать экземпляр организации в вашей базе данных до вызова client.post().

EDIT :

Не могли бы вы сказать мне, как вызвать функцию представления с помощью Запросить объект вручную и макетировать слой модели?

Для первой точки, которую вы хотите Django ' RequestFactory - знайте, что это может быть немного болезненно при настройке. wrt / mocking, я уже связался с соответствующим do c. Я не собираюсь приводить вам подробный пример, потому что это заняло бы гораздо больше времени, чем я могу себе позволить (и уже есть некоторые материалы по топи c).

Как говорится, в вашем случае Я не стал бы беспокоиться об этом в ATM (пока ваш наставник не потребует «правильного» модульного тестирования, но это большая работа, так как вам придется тестировать все задействованные компоненты изолированно, каждый раз со всеми угловыми случаями - и __still_ написать интеграционные тесты выше).

Ваш текущий интеграционный тест может не понравиться пуристам, но он все еще эффективен - он действительно тестирует всю цепочку, и, как я уже сказал, он уже выявил серьезную проблему с вашей реализацией: полное отсутствие обработки ошибок. В реальных программах достаточно часто иметь в три раза больше кода, связанного с ошибками / угловыми случаями / неожиданными условиями, чем то, что фактически необходимо для работы с номинальным случаем.