Интеграция системных тестов в процесс сборки
Я продолжаю разработку генератора слоя сериализации. Пользователь вводит описание типов (в настоящее время в XSD или в WSDL), и программное обеспечение создает код на определенном целевом языке (в настоящее время Java и ANSI C89), который способен представлять описанные типы и который также может сериализоваться (превращается в байтовую последовательность) и десериализует эти значения.
Поскольку генерировать код сложно (я имею в виду, написание кода сложно. Написание кода, который пишет код, - это написание кода для выполнения сложных задач, что является совершенно новой областью сложности:)). Таким образом, в проекте, который предшествовал моей магистерской диссертации, мы решили, что мы хотим провести некоторые системные тесты.
Эти системные тесты знают тип и количество пар значений и последовательностей байтов. Чтобы выполнить системный тест на определенном языке, тип запускается через систе, в результате получается код, как описано выше. Этот код затем связывается с некоторым рукописным кодом хоста, который способен считывать эти пары последовательности байтов и значения и выполняет функции для чтения значений данного значения из строки. Результирующий исполняемый файл затем запускается, и пары байтов-значений подаются в этот исполняемый файл, и в целом проверяется, все ли привязки приводят к выводу "Y". Если это так, то эти примерные значения для типа сериализуются в ранее определенную последовательность байтов, и мы можем сделать вывод, что сгенерированный код компилируется и выполняется правильно, и, таким образом, в целом, часть системы, обрабатывающая этот тип, является правильной. Это очень хорошая вещь.
Однако, сейчас я немного недоволен текущей реализацией. В настоящее время я написал собственный бегун junit, который использует довольно большое колдовство отражений, чтобы считывать эти привязки байтовых значений из атрибутов классов. Кроме того, общий стек для генерации кода требует большого количества шаблонного кода и шаблонных классов, которые делают чуть больше, чем содержат две или три строки. Хуже того, довольно сложно добиться хорошей интеграции со всеми инструментами, основанными на описаниях Junits и генерирующими отчеты об ошибках тестирования. На самом деле довольно сложно отладить то, что происходит, если полезный maven Junit testrunner или тестировщик eclipse сожрали все ошибки, которые выдавал компилятор, просто потому, что формат этой ошибки отличается от собственных ошибок утверждения junits.
Хуже того, один неудачный тест в сгенерированном коде приводит к сбою сборки maven. Это очень раздражает. Мне нравится, если сборка maven завершается неудачей, если не удается выполнить определенный тест другого модуля, потому что (например), если вычисление первого предзаказа на определенную глубину по какой-то причине не удается, все пойдет не так. Однако, если я просто хочу показать кому-то какой-нибудь сгенерированный код для работающего типа, то очень раздражает, если я не могу быстро создать свое приложение, потому что тип, над которым я сейчас работаю, еще не закончен.
Итак, учитывая этот фон, как я могу получить хорошую автоматизированную систему, которая проверяет эти спецификации генерации? Возможности, которые я рассмотрел:
- Интегрированное решение Junit кажется далеко не идеальным, если я не смогу улучшить интеграцию maven, junit и junit со своим бегуном и всем остальным.
- Мы раньше использовали фитнес, но в целом отказались от него, потому что это вызвало больше проблем, чем решило. Основными проблемами, которые у нас были, были интеграция в Maven и Hudson.
- Решение с использованием текстового теста. Я не совсем убежден, потому что это в основном требует исполняемый файл, строки для ввода в stdin и строки, ожидаемые в stdout. Добавление всего "запуска приложения, связи с хост-кодом и ТО запускающего сгенерированного исполняемого файла" кажется довольно сложным.
- Пишу свое собственное решение. Это, конечно, будет работать и делать то, что я хочу. Однако, как обычно, это будет самая трудоемкая задача.
Итак... вы видите другой возможный способ сделать это, избегая при этом писать что-то свое?
1 ответ
Вы можете запустить Maven с -Dmaven.test.skip=true. У Netbeans есть способ установить это автоматически, если вы явно не нажмете одну из команд для тестирования проекта, я не знаю об Eclipse.