Тестовые сценарии компилятора или как протестировать компилятор
Обычно, я сильно против взятия самого дорогого и самого твердого для масштабирования части инфраструктуры (база данных) и вся нагрузка создания в него. С другой стороны: Это значительно упрощает стратегию резервного копирования, особенно когда Вы имеете несколько веб-серверов и должны так или иначе сохранить данные синхронизируемыми.
Как большинство других вещей, Это зависит от ожидаемого размера и Бюджета.
6 ответов
There are several compiler test suites out there. We've had some luck using the Plum Hall test suite for a C compiler. It consists of a large set of C code specifically written to test against the language standard. It verifies that the compiler can handle the language syntax and semantics.
Обычно создается большой набор небольших программ, каждая из которых демонстрирует один из аспектов компилятора. Сюда входят как программы, которые компилируются, так и те, которые не должны. Обычно ASM, выходящий из серверной части, не проверяется, а скорее запускается программа и проверяется ее вывод. Что касается того, как убедиться в отсутствии ошибок в тестовых примерах: сделайте их маленькими, по 5-10 строк каждая.
Эти тестовые наборы могут быть очень большими, от сотен до тысяч тестов (например: ] устаревший набор тестов для языка программирования D ) и обычно включает один или несколько тестовых примеров для каждой когда-либо обнаруженной ошибки.
Компилятор Eiffel является открытым исходным кодом и имеет обширную библиотеку тестовых примеров и внутренних контрактов на проектирование.
Ранее был вопрос, связанный с этим для C , но он сводится к тщательно написанному набору тестов компилятора.
Что касается того, когда компиляторы ошибаются в коде , Я достаточно часто сталкивался с этим за свою профессиональную карьеру, спасибо. Со временем это происходило все реже и реже, но на этой неделе я обнаружил ошибку в компиляторах MS C ++, нацеленных на CLI .
Создание и поддержка хороших наборов тестов для реальных языков обходятся дорого. Есть причина, по которой набор тестов Plum Hall , который является отраслевым стандартом для ANSI C, чертовски дорог.
Проверка перевода Джорджа Некулы - блестящая идея, но также довольно дорогая для реализации.
Единственное, что дешево и легко: поддерживать набор регрессионных тестов, и каждый раз, когда вы исправляете ошибку в вашем компиляторе, добавляйте подходящий тест в ваши наборы регрессий . С компиляторами просто невероятно легко повторять одну и ту же ошибку снова и снова. Дисциплинированные дополнения к вашему набору регрессии предотвратят это, и они стоят недорого.
Относительно идеи скомпилировать большой проект с открытым исходным кодом:
Вы можете взять проект, который сам имеет набор тестов. Затем вы компилируете проект и его набор тестов и смотрите, проходят ли тесты. Чтобы проверить эти результаты, вы компилируете проект и набор тестов с другим компилятором и снова запускаете тесты.