Подтвердить что ты не робот

Написание модульных тестов в Django/Python

Я не использовал Unit Tests раньше, чем простое введение в курс 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? Некоторые примеры были бы приятными.

4b9b3361

ОТВЕТЫ

Ответ 1

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

Нет.

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

  • Что создаёт модель со всеми выполненными полями?

  • Что неполная полная модель терпит неудачу?

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

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

Не так много.

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

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

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

Вы не тестируете Django. Вы тестируете, как ваши бизнес-правила действительно работают в Django.

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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