Тестирование компилятора
В настоящее время я работаю над компилятором, который был построен с использованием sablecc .
Короче говоря, компилятор примет в качестве входных данных как файлы спецификации (это то, что мы анализируем), так и файлы .class, и будет инструментировать байт-код файлов .class, чтобы при запуске файлов .class любые спецификаций не нарушается (это немного похоже на контракты jml / code! но намного мощнее).
У нас есть несколько десятков системных тестов, которые покрывают большую часть фазы анализа (связанных с проверкой соответствия спецификаций имеют смысл, и что они также соответствуют файлам .class, которые они должны указывать).
Мы разделили их на два набора: допустимые тесты и недопустимые тесты.
Допустимые тесты состоят из файлов исходного кода, которые при компиляции нашим компилятором не должны выдавать ошибок / предупреждений компилятора.
Недопустимые тесты состоят из файлов исходного кода, которые при компиляции нашим компилятором должны появиться по крайней мере, одна ошибка / предупреждение компилятора.
Это сослужило нам хорошую службу, пока мы были на этапе анализа. Теперь вопрос в том, как тестировать фазу генерации кода. В прошлом я проводил системные тесты над небольшим компилятором, который я разработал в рамках курса компиляторов. Каждый тест будет состоять из пары исходных файлов на этом языке и output.txt . При запуске теста я бы скомпилировал исходные файлы, а затем запустил его основной метод, проверяя, что выходной результат будет равен output.txt . Конечно, все это было автоматизировано.
Теперь, имея дело с этим более крупным компилятором / инструментарием байт-кода, все не так просто. Нелегко повторить то, что я сделал с помощью моего простого компилятора.Я полагаю, что на данном этапе лучше отказаться от системных тестов и сосредоточиться на модульных тестах.
Как известно любому разработчику компилятора, компилятор состоит из множества посетителей. Я не совсем уверен, как продолжить их модульное тестирование. Из того, что я видел, большинство посетителей вызывают аналогичный класс, у которого есть методы, связанные с этим посетителем (я предполагаю, что идея заключалась в том, чтобы сохранить SRP для посетителей).
Есть несколько приемов, которые я могу использовать для модульного тестирования моего компилятора:
Модульное тестирование каждого метода посетителя отдельно. Это кажется хорошей идеей для посетителей без стека, но ужасной идеей для посетителей, которые используют одну (или несколько) стопок. Затем я также занимаюсь модульным тестированием каждого из других методов из стандартных (читаемых, не посещающих) классов традиционным способом.
Модульное тестирование всего посетителя за один раз. То есть я создаю дерево, которое затем посещаю. В конце я проверяю, правильно ли была обновлена таблица символов. Меня не интересует насмешка над его зависимостями.
То же, что и 2), но теперь насмешка над зависимостями посетителя.
Какие еще?
У меня все еще есть проблема, что модульные тесты будут очень тесно связаны с AST от sabbleCC (который действительно уродлив).
В настоящее время мы не проводим никаких новых тестов, но я бы хотел вернуть поезд в нужное русло, поскольку я уверен, что не тестировать систему - это то же самое, что кормить монстр, который рано или поздно вернется, чтобы укусить нас за задницу, когда мы меньше всего этого ожидаем; - (
Есть ли у кого-нибудь опыт тестирования компиляторов, который мог бы дать какой-нибудь потрясающий совет о том, как действовать сейчас? здесь!