Модульное тестирование для вывода компилятора

Question

В рамках университетского проекта мы должны написать компилятор для игрушечного языка.Чтобы провести некоторое тестирование, я подумал, как лучше написать что-то вроде юнит-тестов.Поскольку компилятор пишется на haskell, Hunit и quickcheck доступны, но, возможно, не совсем уместны.

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

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

Answer 1

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

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

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

Answer 2

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

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

• Arrange: создает среду, в которой функция будет вызываться в
• Act: вызывать функцию
• Подтвердите: проверьте результат

Answer 3

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

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

Answer 4

Взгляните на shelltestrunner .Вот несколько примеров тестов .Он также используется в этом проекте компилятора .

Answer 5

Тестирование становится более сложным, когда вывод вашей программы поступает на консоль (например, стандартный вывод). Затем вам нужно прибегнуть к какому-либо внешнему инструменту, например grep или expect, чтобы проверить вывод.

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