Используйте Slim для синтаксического анализа файла Context.txt теста Fitnesse в Java

Текущая ситуация

В качестве теста перед сборкой я пытаюсь проверить, что любые коммиты / изменения в java-приспособлениях не нарушат никаких фитнес-тестов, которые у меня есть на моем сервере фитнеса.

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

В настоящее время у меня есть HashMap от «имени класса» до «объекта класса» для всех моих доступных java-приспособлений. Я также смог получить доступ ко всем фитнес-тестам в виде файловых объектов. Выглядит это примерно так:

HashMap<String, Class<?>> availableJavaClassesMap = initJavaMap();
List<File> allFitnesseTestFiles = initTestFiles();

Цель

Теперь я хочу сделать что-то вроде этого:

HashMap<String, Method> parsedMethodsFromFitnesseMap;
For(File file: allFitnesseTestFiles) {
    parsedMethodsFromFitnesseMap.addAll( parseFile( file ) );
}

Затем я бы просто сравнил два HashMap и убедился, что parsedMethodsFromFitnesseMap HashMap является подмножеством availableJavaClassesMap HashMap.

Беспокоит

Включить файлы: как обрабатывать парсинг этих первых / других подходов
Сценарии: создайте свой собственный список известных сценариев и того, как они работают

Идеальное решение

Is there an already made parser that will do this?
- I have found the Slim Code and think it could be refactored to my needs.
Это лучший подход для проверки перед сборкой?

Примечание

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

Идеи? Спасибо.

Joe 22.10.2014 источник

Ответы (1)

arrow_upward
0
arrow_downward

Мое решение

Подход, на котором я остановился, заключался в использовании SVNKit для программного извлечения из svn во временную папку системы, а затем мой анализ и сравнение между методами, а затем удаление каталога, когда я закончил.

Что касается времени выполнения, если я вытащил и проанализировал 200 тестов, это заняло около 20 секунд. Однако около 90% времени занимает простое извлечение тестов из репозитория svn.

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

Я позаботился о том, чтобы файлы импорта были проанализированы заранее, чтобы их сценарии можно было использовать при анализе реальных тестов.

В итоге я не использовал какой-либо тонкий код (однако, если вы хотите попробовать, класс InstructionExecutor был тем, что я считал наиболее полезным / близким к синтаксическому анализатору.

Это был довольно простой подход, и я бы порекомендовал его.