Написание юнит-тестов в Django / Python - PullRequest
29 голосов
/ 21 января 2009

Я не пользовался модульными тестами, кроме краткого введения в курс Uni. В настоящее время я пишу заявление и хотел бы научить себя TDD в процессе. Проблема в том, что я не знаю, что тестировать или как на самом деле.

Я пишу приложение Django, и до сих пор создал только модели (и настроил приложение администратора). Вот как я написал скелеты моих тестов:

class ModelTests(TestCase):
    fixtures = ['initial_data.json',]

    def setUp(self):
        pass

    def testSSA(self):
        ssa = SSA.objects.create(name="sdfsdf", cost_center=1111, street_num=8,
                street_name="dfsdfsf Street", suburb="sdfsdfsdf",
                post_code=3333)


    def testResident(self):
        pass

    def testSSA_Client(self):
        pass

Я планировал написать функцию для тестирования каждой модели в классе ModelTests. Это хороший способ написания тестов? Кроме того, что именно я должен проверять? Что создание модели со всеми полями завершено работами? Что наполовину полная модель терпит неудачу? Что какие-то особые случаи тестируются (например, null и is_required = False)? Я доверяю ORM, который, насколько я знаю, подвергается тщательному тестированию, поэтому мне не нужно проверять все методы, если я?

Что мне нужно проверить для веб-приложения, написанного на Django / Python? Некоторые примеры были бы хороши.

Ответы [ 3 ]

37 голосов
/ 21 января 2009

Является ли функция для тестирования каждой модели в классе ModelTests хорошим способом написания тестов?

номер

Что именно я должен проверять?

  • Что при создании модели со всеми полями завершены работы?

  • Что, неполная модель не работает?

  • Что проверяются какие-либо особые случаи (например, null и is_required = False)?

  • Я доверяю ORM, который, насколько я знаю, подвергается тщательному тестированию, поэтому мне не нужно проверять все методы, не так ли?

Не так много.

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

Для каждого класса Model вам потребуется хотя бы одно определение класса TestCase. Тестовые наборы дешевы, определите их много.

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

Ты не тестируешь Джанго. Вы проверяете, как на самом деле работают ваши бизнес-правила в Django.

Позже, когда в вашем приложении появятся дополнительные материалы (формы, представления, URL-адреса и т. Д.), Вы захотите использовать клиентский модуль Django для тестирования каждого метода для каждого URL-адреса. Опять же, один TestCase на

10 голосов
/ 21 января 2009

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

Во-первых, прочитайте главу о модульном тестировании «Погружение в Python» (это бесплатно онлайн! http://diveintopython3.ep.io/unit-testing.html), Это отличное объяснение модульного тестирования в целом, что вам нужно делать и почему.

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

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

4 голосов
/ 21 января 2009

Предположительно, вы уже читали Тестирование Приложения Django .

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

Имитируйте запросы GET / POST для ваших URL-адресов и наблюдайте за ответами (заголовки, коды состояния и контент). Правильно ли отображено ваше приложение? Используя правильный шаблон? В разделах, где ваше приложение генерирует исключения, попытайтесь их вызвать (например, просмотреть / отредактировать несуществующую запись, чтобы вызвать ObjectDoesNotExist).

Обычно стоит установить систему отслеживания (например, Trac), чтобы вы могли добавить новый тест для каждого зарегистрированного дефекта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...