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

Question

Как вы проверяете, возвращает ли скомпилированный код ожидаемый результат или не работает, как ожидалось?

Я разработал рабочий пример ниже, но это нелегко растягивается. Для каждого дополнительного теста потребуются дополнительные скобки для вложенности. Конечно, я мог бы разделить это на другие файлы, но есть ли у вас какие-либо предложения по улучшению этого ?. Также я планирую использовать это из make test stanza в make-файле, поэтому я не ожидаю, что другие люди установят что-то, что не установлено по умолчанию, просто для его тестирования. И stdout также должен чередоваться с stderr.

упрощенный пример:

./testFoo || echo execution failed 

./testBar && echo expected failure 

(./testBaz && (./testBaz 2>&1 | cmp -s - foo.tst && (./testFoo && echo and so on 
    || echo testFoo's execution failed)|| echo testBaz's does not match ) 
    || echo testBaz's execution failed 

мой текущий тестер выглядит следующим образом (для одного теста):

\#!/bin/bash 
compiler1 $1 && (compiler2 -E --make $(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/') && (./$(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/') || echo execution failed) || less $(echo $1 | sed 's/^\(.\)\(.*\)\..*$/\l\1\2/').err) || echo compile failed 

Answer 1

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

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

Например, файл testFoo.exec с содержанием 0 означает, что он должен добиться успеха (или по крайней мере возвращения с 0), тогда как testBar.exec будет содержать 1.

textBaz.out будет содержать ожидаемый выход. Вам не нужно вызывать testBaz несколько раз; вы можете перенаправить вывод в первый вызов, а затем посмотреть на $?, чтобы узнать, был ли вызов успешным или нет. Если это так, вы можете напрямую проверить вывод (без повторного запуска команды).

Answer 2

Мой собственный наивным тест Жгут работает так:

• каждый тест представлен Баш скрипт с расширением .test - все они живут в том же каталоге

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

• основной тестовый скрипт находит все сценарии .test и выполняет каждый из них по очереди, создавая временный выходной файл. Это diff'd с файлом согласования в каталоге good_results и любые различия сообщили

ITV взял меня около получаса, чтобы написать это и заставить его работать, но он оказался бесценным!