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