Написание тестовых случаев для моделей Django - PullRequest
Новая
       30

Написание тестовых случаев для моделей Django

34 голосов
/ 06 марта 2012

На полпути моего текущего проекта, после того, как мне пришлось потратить бесчисленные минуты на отладку, я решил использовать TDD.Для начала я планирую написать набор модульных тестов для каждой из существующих моделей.Но для моделей, которые имеют только определенные атрибуты (т. Е. Без дополнительных методов / свойств), я не уверен, что мне нужно тестировать и как.

class Product(models.Model):
    name = models.CharField(max_length=50)
    description = models.TextField(default='', blank=True)
    retails = models.ManyToManyField(Retail, verbose_name='Retail stores that carry the product')
    manufacturer = models.ForeignKey(Manufacturer, related_name='products')
    date_created = models.DateTimeField(auto_now_add=True)
    date_modified = models.DateTimeField(auto_now=True)

Используя в качестве примера Product , что нужно учитывать в модульных тестах?И как должны быть покрыты ForeignKey и ManyToManyField ?

Ответы [ 2 ]

71 голосов
/ 06 марта 2012

Это была статья, которую я нашел полезной: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-django/. Вот хорошее резюме того, что тестировать:

Еще одна распространенная проблема для разработчиков / дизайнеров, плохо знакомых с тестированием, - это вопрос«Что я должен (или не должен) проверять?»Хотя здесь нет жестких и быстрых правил, которые аккуратно применяются повсюду, есть некоторые общие рекомендации, которые я могу предложить при принятии решения:

  • Если рассматриваемый код является встроенным Pythonфункция / библиотека, не проверяйте это.Примеры, такие как библиотека даты и времени.

  • Если соответствующий код встроен в Django, не проверяйте его.Примеры, такие как поля в модели или тестирование того, как встроенный шаблон. Узел отображает включенные теги.

  • Если в вашей модели есть пользовательские методы, вы должны проверить это, обычно с помощью модульных тестов.

  • То же самое касается пользовательских представлений, форм, тегов шаблонов, обработчиков контекста, промежуточного программного обеспечения, команд управления и т. Д. Если вы внедрили бизнес-логику, вам следует проверить свои аспекты кода.

Так что, для вашего примера, на самом деле ничего не будет проверяться, пока вы не напишите некоторые пользовательские функции.
На мой взгляд, тестирование ForeignKey и ManyToManyField ссылки попадают во вторую категорию (код, встроенный в Django), поэтому я бы не стал их проверять, так как вы действительно проверяете, работает ли Django правильно.Если у вас есть метод, который создает экземпляр вашего продукта, включая внешние связи и M2M, вы можете проверить, созданы ли данные, которые будут проверять ваш пользовательский метод, а не функциональность Django.

Использование парадигмы TDDтесты созданы для проверки бизнес-логики и требований к дизайну.

0 голосов
/ 14 июля 2019

В моем TDD класса CS350 указано, что рекомендуется проверять все методы доступа и мутаторы. Таким образом, для модели вы должны сначала написать тесты, которые вызывают каждую функцию оценщика и убедиться, что она возвращает правильное значение.

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

Для перезапуска: если модель имеет поля a, b и c, вы должны создать экземпляр, используя ваш конструктор, а затем активировать, чтобы все три были установлены правильно. Скажем, есть еще одна функция, set_a (). Вы могли бы утверждать, что изменилось не только значение «a», но что значения b и c остаются неизменными.

...