Автоматизированное тестирование двоичных файлов из SVN на HPC - PullRequest
Новая
       59

Автоматизированное тестирование двоичных файлов из SVN на HPC

1 голос
/ 26 июня 2009

Я хотел бы настроить автоматическое тестирование тестовых примеров на двоичные файлы Fortran в репозитории SVN, по запросу или с заданием Cron. Чтобы немного усложнить проблему, тестовые случаи будут выполняться на вычислительном кластере, так что каждый тестовый сценарий должен будет генерировать сценарий PBS. (Linux Environment)

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

Есть ли какие-либо предложения о том, как к этому приблизиться?

Ответы [ 3 ]

1 голос
/ 26 июня 2009

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

, например 

for each program
    compile
    submit to queue
    wait for finish
    check output

На практике вы, вероятно, захотите отправить в очередь более одной работы, но идея та же.

Вот несколько идей о том, как вы можете сделать каждый шаг.

Подающий

Вы можете использовать шаблонный сценарий PBS и использовать sed для поиска / замены входных токенов входными значениями для программы перед отправкой

В ожидании финиша

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

Проверить вывод

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

1 голос
/ 26 июня 2009

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

Поскольку вы работаете в пакетной системе, у вас есть некоторая свобода для планирования тестов. Возможно, вы захотите иметь общее задание «проверки», для которого вы можете предоставить параметры настройки (например, для местоположений ожидаемых и фактических выходных данных программы). Ник упоминается с использованием grep для проверки вывода qstat для вашего идентификатора задания, но вы можете указать PBS удерживать задание до завершения другого задания. Это будет означать, что у вас есть что-то вроде: 

...
#PBS -N run_test_1
#PBS -a 200906270000
...
<compile test>
<run test>
<save output>

при отправке сохраните идентификатор задания, возвращаемый qsub (то, как вы это сделаете, зависит от вашей платформы - обычно достаточно что-то вроде job_id=$(qsub $JOB_FILE)). Затем подключите это значение к другому сценарию: 

...
#PBS -N verify_test_1
#PBS -W depend=afterany:$job_id
<run comparison>
...

Это будет (при вводе правильного значения job_id) задержать выполнение тестового прогона до полуночи 27 июня 2009 г. и приостановит выполнение тестового задания до завершения тестового задания (afterany директива указывает, что она всегда должна запускаться после первого задания, а не только в случае его успешного выполнения.

Однако, в зависимости от времени оборота вашего кластера, вы можете поместить все это в один сценарий, хотя вы все равно можете использовать основанные на времени задержки PBS для запуска только в определенное время. Недавно я начал использовать Python вместо сценариев оболочки для обработки даже этих системных задач - вчера я тестировал создание исполняемого сценария Python и добавление директив PBS прямо в исходный код - он работал очень хорошо.

1 голос
/ 26 июня 2009

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

http://buildbot.net/

...