Тестирование целых программ. лучшие практики

Question

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

Однако, когда дело доходит до тестирования программ, все меняется. Для тестирования программы должны выполняться в целом. Программы предполагают найти установленную библиотеку (что может быть и так, хотя и неверно, если я установил предыдущую версию на моей машине, добавив дополнительные проблемы). На данный момент мои программы запускаются testuite с определением PYTHONPATH, которое я выполняю вручную, перед развертыванием (IOW, я не выполняю установку), но я не думаю, что я делаю это правильно. Я чувствую, что в целом, программа должна быть проверена на функциональность, когда она полностью развернута, но это будет означать, что я должен установить ее каждый раз, когда я хочу выполнить функциональное тестирование.

Каков ваш опыт и предложения относительно функционального тестирования целых программ? вы делаете это до или после развертывания, и как?

Благодаря

Обратите внимание, что я не включаю питон метку на цели. Хотя моя проблема связана с python, и я предпочел бы ответы на вопросы, связанные с python, я думаю, что вклад может быть внесен также экспертами на других языках.

---

Редактировать: как сообщалось в комментарии, тот факт, что моя программа, при установке, необходимо импортировать модули, чьи пути могут быть найдены только при развертывании (загрузить и установить зависимости на лету, они не установлены на моей машине). Я не могу манипулировать sys.path из теста, потому что это будет означать, что я изменяю sys.path программы (мой исполняемый файл) из другой программы (testuite, которая запускает и вызывает вызов system()).

Другими словами, единственный способ, которым я должен протестировать программу без развертывания, - это запустить программу с PYTHONPATH, установленную в каталог, содержащий депилы, и библиотеку, которая использует программу, установленную скриптом make (что, как я уже сказал , загружает, компилирует и «устанавливает» все во временный каталог).

При развертывании распаковки и исполняемые файлы упаковываются вместе в структуру типа «OSX bundle», которая полностью исполняема и перемещается.

Edit:

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

Edit:

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

Answer 1

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

Итак, в вашем случае, насколько я понимаю, вы хотите протестировать свое приложение в целом на функциональном уровне. Так что это нужно сделать против требований.

Таким образом, вам нужен документ с требованием, будь то полнотекстовый сценарий или (лучше) диаграмма примера использования UML, охватывающая (в идеале широко) варианты использования вашего приложения (обычно это одна из первой фазы, которая должна быть достигнута). Затем вам необходимо написать тестовые примеры, охватывающие все варианты использования, и передать эти тестовые примеры. Это можно сделать с помощью ручного или автоматического тестирования с помощью известных (и довольно дорогих) инструментов.

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

В вашем случае, если установщик является безошибочным, и вы на 100% уверены, что тестирование перед развертыванием с использованием переменной PYTHONPATH никогда не приведет к ошибке после развертывания, тогда вы можете протестировать ее перед развертыванием. Это чистое управление рисками, и это ваш звонок, потому что вы тот, кто знает лучшие про и минусы этого для ваших приложений. (Personnaly, я не понимаю, почему ошибки не могут существовать там, они везде :-))

Надежды, что помогает, и я не совсем теме

Answer 2

Ну, (автоматизированное) тестирование всегда является компромиссом, поэтому нет единственного правильного пути для этого.

Но да, в идеале вы должны автоматически выполнить полную установку/развертывание своей программы перед запуском тестов. Таким образом, вы также проверяете свой установщик.

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

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

Answer 3

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

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

Answer 4

We «ве столкнулся с аналогичной проблемой о развертывании и используют virtualenv для тестирования развертываний. Специально с опцией --no-site-packages, это похоже на первоначальную установку и не сбрасывает PYTHONPATH за хорошо проверенное стороннее решение. И, чтобы быть уверенным, мы запускаем всю вещь, virtualenv и все, на новой виртуальной машине.

btw, полезный трюк с virtualenv s is ./setup.py develop.

(от одного подмастерья к другому ...)

Answer 5

наверняка вы должны проверить вашу программу в совершенно точных сценариев после развертывания.

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

Существует множество методов для этого. Если вы развертываете веб-службу, самотестирование можно вызвать с помощью административного URI, который сделает HTTP-запросы на себя, чтобы убедиться, что они работают. Статические самотестирования, вероятно, все, что вам нужно, но вы также можете загружать и запускать тестовые сценарии динамически. Для последнего вы можете использовать возможности интерпретации своего языка, или, если их нет, вы можете встроить в свой программник интерпретатор (например, TCL для C/C++ и Rhino для Java) или написать собственный мини-интерпретатор.

Answer 6

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

Лучшее, что нужно сделать, - это иметь небольшую бизнес-логику в вашей части приложения, тогда вы можете лучше протестировать, так как вы можете протестировать контроллеры вниз, или если у вас есть, ваши службы веб-поиска/REST сверху вниз.

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

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