Как протестировать программное обеспечение, использующее внешние инструменты командной строки - PullRequest
1 голос
/ 26 мая 2009

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

Ответы [ 5 ]

5 голосов
/ 26 мая 2009

Вы можете запоминать (http://en.wikipedia.org/wiki/Memoization) внешние процессы. Напишите оболочку в Ruby, которая вычисляет сумму md5 входного файла и проверяет ее по базе данных известных контрольных сумм. Если она совпадает, скопируйте справа вывод, в противном случае вызовите инструмент как обычно.

3 голосов
/ 26 мая 2009

Ответ в 90% состоит в том, чтобы высмеивать внешние инструменты командной строки и проверять, что им передается правильный ввод на разделяющем интерфейсе между ними. Это помогает поддерживать быстрый набор тестов. Кроме того, вам не нужно вводить инструменты командной строки, так как они не являются «тестируемым кодом» - это дает возможность того, что модульный тест может не пройти из-за изменений в вашем коде или некоторых изменений в поведении команды. Утилита линии.

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

3 голосов
/ 26 мая 2009

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

2 голосов
/ 26 мая 2009

Если внешние программы хорошо протестированы, вам следует просто проверить, что ваша программа передает им правильные данные.

1 голос
/ 26 мая 2009

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

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

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

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

Вы должны решить, являются ли эти последние тесты полезными или нет. Это очень сильно зависит от используемых инструментов.

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