Написание тестовых примеров для моделей django

На полпути к моему текущему проекту, после того, как я страдаю от тяги, затрачиваемой на отладку несчетных минут, я решил принять 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)

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

Ответ 1

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

Другим распространенным препятствием для разработчиков/дизайнеров, новых для тестирования, является вопрос о том, что я должен проверить (или не должен)? " Пока нет жесткие и быстрые правила здесь, которые аккуратно применяются повсюду, есть некоторые общие рекомендации, которые я могу предложить при принятии решения:

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

Если этот код встроен в Django, не проверяйте его. Примеры, например, поля на модели или тестирование встроенного template.Node отображает включенные теги.

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

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

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

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

Ответ 2

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

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

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