Как проверить модули / сценарии, которые выводят / изменяют файлы? - PullRequest
Новая
       22

Как проверить модули / сценарии, которые выводят / изменяют файлы?

3 голосов
/ 03 августа 2010

У меня есть пара модулей ( DZP :: Catalyst и DZP :: OurPkgVersion ), обе из которых предназначены для записи файлов на диск.Я не уверен, как их протестировать, есть ли хорошие стратегии для тестирования файлов, записанных на диск?в любое место, куда я мог бы пойти, чтобы прочитать об этом?

Ответы [ 2 ]

3 голосов
/ 03 августа 2010

Это зависит от модуля, но моя общая стратегия:

  • Убедитесь, что логика содержимого файла отделена на 100% - если она отличается от различных методов - от механики файла (например, выбор каталога / открытие файлов / закрытие файлов / обработка ошибок).

  • Убедитесь, что механика файлов на 100% гибкая, например, Вы можете выбрать каталог / имя файла из внешнего драйвера.

  • Записать тесты для файловой механики, просто открыв указанный файл в указанном каталоге, закрыв его, убедившись, что ошибок не было, и что ожидаемый файл существует и имеет нулевой размер

  • создать массив тестовых данных, каждый элемент которого состоит из 3 частей

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

    2. Ожидаемое имя файла для установки

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

      Архив ожидаемых результатов должен находиться в отдельном подкаталоге (скажем, «ожидаемые_результаты» в каталоге, где находится ваш тестовый скрипт.

      Вам нужен tarball, если ваша логика генерации файла выдает> 1 файл.

    1036 **

  • Затем выполните цикл для каждого теста в массиве тестов, который вы ранее создали:

    1. Создайте новый временный каталог "фактических результатов" (или очистите тот из предыдущего теста)

    2. Установить каталог в вашем модуле на временный каталог; установите имя файла вашего модуля на ожидаемое имя файла из тестовой информации.

    3. Запустить метод открытия файлов (ранее проверенный)

    4. Запустите логику генерации контента из модуля, используя логические указания теста (если применимо) и входные данные теста.

    5. Запустить метод закрытия файла (ранее проверенный)

    6. Создать временный каталог с ожидаемыми временными результатами (или очистить тот, что был в последнем тесте)

    7. Скопировать тарбол "ожидаемые результаты" из подкаталога теста "Ожидаемые результаты" во временный каталог "ожидаемые результаты", созданный в последней точке маркера

    8. распакуйте этот архив в временный каталог «ожидаемые результаты» и удалите из него архив.

    9. directory-diff - временный каталог временных ожидаемых результатов с временным каталогом фактических результатов (например, убедитесь, что оба имеют 100% одинаковый список файлов и что содержимое каждого файла на 100% одинаковое, либо через собственный Perl или используя diff через system() звонки.

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

3 голосов
/ 03 августа 2010

Ну, в данном конкретном случае ( Dist :: Zilla плагины) вы захотите использовать Dist :: Zilla :: Tester . Он берет на себя большую часть тяжелой работы по созданию временного каталога, заполнению его файлами и последующей очистке. Например, см. тесты из моего DZP :: CJM или тесты из самого Dist :: Zilla , особенно каталог плагинов .

Обновление: Dist :: Zilla 4.200002 представил модуль Test :: DZil , который добавляет некоторые служебные функции, полезные для тестирования плагинов. Возможно, вы захотите использовать его вместо непосредственного использования Dist :: Zilla :: Tester.

...