модульное тестирование для сервера приложений

Question

Я написал сервер приложений (с использованием Python и Twisted), и я хочу начать писать некоторые тесты. Но я не хочу использовать Twisted's Trial из-за нехватки времени и не имею времени играть с ним сейчас. Итак, вот что я имею в виду: напишите небольшой тестовый клиент, который подключается к серверу приложений и делает необходимые запросы (протокол связи - это некоторый внутренний XML), статически хранит полученный XML, а затем пишет некоторые тесты. на этих статических данных, используя unitest.

Мой вопрос: правильный ли это подход, и если да, то какие тесты охватываются этим подходом?

Кроме того, использование этого метода имеет ряд недостатков, таких как: невозможность доступа к уровню базы данных для построения / перестройки схемы, когда тестовый клиент будет подключаться к серверу: для каждого модульного теста или перед запуском тестовый набор?

Answer 1

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

import unittest

вы должны написать

from twisted.trial import unittest

... и тогда вы можете вернуть Deferreds из ваших test_ методов. Практически все остальное тоже самое.

Еще одно отличие состоит в том, что вместо создания гигантского тестового объекта в нижней части модуля и запуска

python your/test_module.py

Вы можете просто определить свои тесты и затем запустить

trial your.test_module

Если вы вообще не заботитесь об интеграции реактора, вы можете просто запустить trial на наборе существующих модульных тестов Python. Пробная версия поддерживает модуль стандартной библиотеки unittest.

Answer 2

«Мой вопрос: правильный ли это подход?»

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

«Какие тесты охватываются этим подходом?»

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

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

"не удалось получить доступ к уровню базы данных для построения / перестройки схемы",

Почему бы и нет? Это Питон. Напишите отдельный инструмент, который импортирует этот слой и выполняет построение базы данных.

"когда тестовый клиент будет подключаться к серверу: за каждый модульный тест или до запуска набора тестов?"

Зависит от цели теста. Зависит от ваших вариантов использования. Что происходит в «реальном мире» с вашими реальными предполагаемыми клиентами?

Вы захотите протестировать поведение, подобное клиенту, устанавливая соединения так, как клиенты устанавливают соединения.

Кроме того, вы захотите протестировать ненормальное поведение, например, когда клиенты сбрасывают соединения или делают что-то не по порядку или не подключаются.

Answer 3

Я думаю, что вы выбрали неправильное направление. Это правда, что пробные документы очень легкие. Но Trial основан на unittest и только добавляет некоторые вещи, чтобы иметь дело с циклом реактора и асинхронными вызовами (не легко написать тесты, которые имеют дело с deffers). Все ваши тесты, которые не включают в себя вызов deffer / asynchronous, будут точно такими же, как при обычном unittest.

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

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

Answer 4

раньше не использовал витой, и документация по витой / пробной версии не является звездной из того, что я только что видел, но, вероятно, вам потребуется 2-3 дня, чтобы правильно внедрить тестовую систему, которую вы описали выше. Теперь, как я уже сказал, я понятия не имею о пробной версии, но я думаю, что вы, вероятно, сможете заставить ее работать через 1-2 дня, поскольку у вас уже есть приложение Twisted. Теперь, если Trial даст вам больше освещения за меньшее время, я бы пошел с Trial.

Но помните, что это просто ответ из очень беглого взгляда на документы