Можно ли программно генерировать тестовые наборы и наборы JUnit? - PullRequest
16 голосов
/ 30 октября 2009

Мне нужно написать очень большой набор тестов для сложного набора бизнес-правил, которые в настоящее время фиксируются в нескольких табличных формах (например, если параметры X Y Z такие-то и такие, значение должно быть между V1 и V2). У каждого правила есть имя и своя семантика.

Моя конечная цель - создать набор тестов, разбитый на наборы дополнительных тестов, с тестовым набором для каждого правила.

Один из вариантов - на самом деле жестко закодировать все эти правила в качестве тестов. Это уродливо, отнимает много времени и негибко.

Другой - написать скрипт на Python, который будет читать файлы правил и генерировать классы Java с помощью модульных тестов. Я бы предпочел избежать этого, если смогу. Другой вариант - использовать Jython.

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

Есть ли разумный способ справиться с этим, используя только Java?

Обновление: возможно, я несколько упростил наши правила. Некоторые из них действительно являются табличными (стиль Excel), другие более размыты. Общий вопрос, тем не менее, остается, так как я, вероятно, не первый человек, который имеет эту проблему.

Ответы [ 4 ]

17 голосов
/ 30 октября 2009

В JUnit 4 вы захотите взглянуть на Параметризованный бегун . Он был создан для целей, которые вы описываете (тесты на основе данных). Однако он не организует их в люксы.

В Junit 3 вы можете создавать TestSuites и тесты программно. Ответ в Junit Recipes , который я могу расширить, если вам это нужно (помните, что JUnit 4 может выполнять тесты Junit 3).

8 голосов
/ 30 октября 2009

Рассматривали ли вы использовать FIT для этого?

Кажется, у вас уже есть готовые таблицы, а «бизнес-правила» звучат так, как будто «деловые люди пишут их с помощью Excel».

FIT - это система проверки тестов на основе таблиц с входными данными -> ожидаемыми выходными сопоставлениями, и доступна библиотека Java с открытым исходным кодом для выполнения этих тестов.

1 голос
/ 01 ноября 2009

Мы попробовали FIT и решили пойти с Concordion . Основными преимуществами этой библиотеки являются:

  • тесты могут быть зарегистрированы вместе с базой кода (например, в хранилище Subversion)
  • они выполняются стандартным бегуном JUnit
0 голосов
/ 05 ноября 2009

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

Мой тест выглядел примерно так:

void setup() { 
  cases = read in the xml file
}

void test_fn_works() {
  for case in cases {
    assert(case.expected_result, fn(case.inputs), 
        'Case ' + case.inputs + ' should yield ' + case.expected_result);

  }
}

С Руби я сделал именно то, что вы говорите - генерируя тесты на лету. Делать это на Java, однако, сложно, и я не думаю, что оно того стоит, поскольку есть другой, вполне разумный подход.

Надеюсь, это поможет.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...