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

Question

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

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

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

Answer 1

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

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

" на какие тесты распространяется этот подход? "

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

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

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

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

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

Зависит от цели теста. Зависит от ваших вариантов использования. Что происходит в & "Реальном мире"! " с вашими фактическими предполагаемыми клиентами?

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

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

Answer 2

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

import unittest

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

from twisted.trial import unittest

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

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

python your/test_module.py

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

trial your.test_module

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

Answer 3

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

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

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

Answer 4

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

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