Тестирование на согласованность внешних ресурсов / пропуск тестов django - PullRequest
2 голосов
/ 13 июля 2010

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

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

По сути, я хотел бы протестировать свой внешний источник, не будучи зависимым от него!

Набор тестов Django использует модуль юнит-тестов Python (по крайней мере, так ям), что выглядит полезным, учитывая, что документация для него описывает Пропуск тестов и ожидаемые сбои .Эта функция, по-видимому, «новая в версии 2.7», что объясняет, почему я не могу заставить ее работать - я проверил установленную мной версию unittest с консоли, и она выглядит как 1.63!

Я не могу найти более позднюю версию unittest в pypi, поэтому Мне интересно, где я могу получить версию unittest, описанную в этом документе и будет ли она работать с Django (1.2).

Я, очевидно, открыт для рекомендаций / обсуждения того, является ли это лучшим подходом к моей проблеме:)

[ РЕДАКТИРОВАТЬ - дополнительная информация/ уточнение]

Как я уже сказал, я явно высмеиваю зависимость и провожу свои тесты по этому вопросу.Однако я также хотел бы иметь возможность проверить, что внешний ресурс (который обычно будет API) по-прежнему соответствует моему ожидаемому формату, не снижая CI, если есть проблема с сетью или их сервер временно недоступен.Я просто хочу проверить согласованность ресурса.

Рассмотрим следующий случай ...

Если вы написали приложение для Twitter, у вас будут тесты для всех методов и поведений вашего приложения.- они будут использовать поддельные данные Twitter.Это дает вам полный, автономный набор тестов для вашего приложения.Проблема в том, что на самом деле это не проверяет, работает ли приложение, потому что ваше приложение по своей сути зависит от согласованности API Twitter.Если бы Twitter изменил вызов API (возможно, изменил URL, параметры или ответ), приложение перестало бы работать, даже если модульные тесты все равно пройдут.(Или, возможно, если бы они полностью отключили обычную аутентификацию !)

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

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

Извиняюсь за длинный вопрос, я знаю, что большинство людей не будут читать это сейчас.Я выделил важные биты, чтобы их было легче читать.

Ответы [ 3 ]

1 голос
/ 14 июля 2010

Я создал отдельный ответ, так как ваше редактирование аннулировало мой последний ответ.

Я предполагаю, что вы работаете в Python версии 2.6 - я думаю, что изменения, которые вы ищете в unittest, доступны в Python версии 2.7. Поскольку unittest находится в стандартной библиотеке, обновление до Python 2.7 должно сделать эти изменения доступными для вас. Это вариант, который будет работать для вас?

Еще одна вещь, которую я мог бы предложить, - это, возможно, разделить тест (ы) "проверки формата внешнего источника" на отдельный набор тестов и запустить его отдельно от остальных ваших модульных тестов. Таким образом, ваши базовые модульные тесты все еще бывают быстрыми, и вам не нужно беспокоиться о внешних зависимостях, нарушающих ваши основные наборы тестов. Если вы используете Hudson, должно быть довольно легко создать отдельную работу, которая будет выполнять эти тесты для вас. Просто предложение.

1 голос
/ 11 сентября 2010

Новые функции в unittest в 2.7 были перенесены в 2.6 как unittest2. Вы можете просто установить и заменить unittest2 на unittest, и ваши тесты будут работать так же, как и вы, плюс вы получите новые функции без обновления до 2.7.

0 голосов
/ 13 июля 2010

Что вы пытаетесь проверить? Код в ваших приложениях Django или зависимость? Можете ли вы просто издеваться над этой внешней зависимостью? Если вы просто хотите протестировать свое приложение на Django, я бы сказал, «Моделируйте внешнюю зависимость», поэтому ваши тесты не зависят от доступности этого внешнего ресурса.

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

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