Слюни тестирование с джунитом

Question

Как лучше всего проверять правила слюней с помощью junit?

До сих пор мы использовали junit с dbunit для проверки правил. У нас были образцы данных, которые были помещены в hsqldb. У нас было несколько пакетов правил, и к концу проекта очень трудно сделать хороший тестовый ввод, чтобы проверить одни правила и не запускать другие.

Таким образом, точный вопрос заключается в том, как я могу ограничить тесты в junit одним или несколькими определенными правилами для тестирования?

Answer 1

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

Вы можете написать изолирующие тесты с помощью AgendaFilter и StatelessSession

StatelessSession session = ruleBase.newStatelessSesssion();

session.setAgendaFilter( new RuleNameMatches("<regexp to your rule name here>") );

List data = new ArrayList();
... // create your test data here (probably built from some external file)

StatelessSessionResult result == session.executeWithResults( data );

// check your results here.

Источник кода: http://blog.athico.com/2007/07/my-rules-dont-work-as-expected-what-can.html

Answer 2

Я создал простую библиотеку, которая помогает писать модульные тесты для Drools. Одной из функций является именно то, что вам нужно: объявите конкретные файлы drl, которые вы хотите использовать для модульного теста:

@RunWith(DroolsJUnitRunner.class)
@DroolsFiles(value = "helloworld.drl", location = "/drl/")
public class AppTest {

    @DroolsSession
    StatefulSession session;

    @Test
    public void should_set_discount() {
        Purchase purchase = new Purchase(new Customer(17));

        session.insert(purchase);
        session.fireAllRules();

        assertTrue(purchase.getTicket().hasDiscount());
    }
}

Для получения более подробной информации смотрите сообщение в блоге: http://maciejwalkowiak.pl/blog/2013/11/24/jboss-drools-unit-testing-with-junit-drools/

Answer 3

Модульный тест с DBUnit на самом деле не работает. Интеграционный тест с DBUnit делает. Вот почему: - Юнит тест должен быть быстрым. - Восстановление базы данных DBUnit происходит медленно. Легко занимает 30 секунд. - Реальное приложение имеет много не пустых столбцов. Таким образом, данные, выделенные для одной функции, все еще легко используют половину таблиц базы данных. - Юнит тест должен быть изолирован. - Восстановление базы данных dbunit для каждого теста, чтобы держать их изолированными, имеет недостатки: --- Выполнение всех тестов занимает часы (особенно по мере роста приложения), поэтому никто не запускает их, поэтому они постоянно ломаются, поэтому они отключены, поэтому тестирование не выполняется, поэтому ваше приложение полно ошибок. --- Создание половины базы данных для каждого модульного теста - это большая работа по созданию, большая работа по обслуживанию, которая может легко стать недействительной (что касается проверки, которую не поддерживает схема базы данных, см. Hibernate Validator) и обычно плохо работа по представлению реальности.

Вместо этого, напишите интеграционные тесты с DBunit: - Один DBunit, одинаковый для всех тестов. Загрузите его только один раз (даже если вы запустите 500 тестов). - Завершение каждого теста в транзакции и откат базы данных после каждого теста. Большинство методов используют распространение, необходимое в любом случае. Устанавливайте только тестовые данные грязными (чтобы сбросить их в следующем тесте, если есть следующий тест) только тогда, когда для распространения требуется require_new. - Заполните эту базу с угловыми случаями. Не добавляйте больше общих случаев, чем строго необходимо для проверки ваших бизнес-правил, поэтому обычно только 2 общих случая (чтобы иметь возможность проверить «один ко многим»). - Написать тесты на будущее: - Не проверяйте количество активированных правил или количество вставленных фактов. - Вместо этого проверьте, присутствует ли в результате определенный вставленный факт. Отфильтруйте результат по определенному свойству, установленному в X (отличается от общего значения этого свойства), и проверьте количество вставленных фактов с этим свойством, установленным в X.

Answer 4

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

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

Что касается примеров данных, я предпочитаю использовать статические данные и определятьминимальные данные теста для каждого теста.Есть несколько способов сделать это, но программное создание объектов фактов в Java может быть достаточно хорошим.

Answer 5

Разделите правила по техническому / бизнес-значению и разделите сами бизнес-правила, чтобы загрузить в сеанс те правила, которые вы хотите проверить вместе. Например, вы можете загрузить в сеанс все технические правила, таблицы общих решений и т. Д. И один файл бизнес-правил для проверки всех возможных бизнес-сценариев. Вы также можете провести «интеграционный тест» и загрузить все правила в один сеанс для тестирования фиктивных сценариев интеграции.

Рассмотрим простую библиотеку, которая оборачивает сессию drools и предоставляет вам несколько тестов 'sugar'. Вы можете определить сложный шаблон, какие ресурсы загружать декларативным способом, и установить, какие правила вы ожидаете, чтобы запускаться в аннотации. Он сохранит ошибки внутреннего утверждения и сообщит о любых правилах, вызывающих несоответствие, которое дает вам подсказку, что сразу пошло не так. Регистрация проливает свет на причинно-следственные связи между событиями. Работает с SpringRunner.class для пружинных интеграционных испытаний.

Пример:

@DroolsSession(resources = {
        "classpath*:/org/droolsassert/rules.drl",
        "classpath*:/com/company/project/*/{regex:.*.(drl|dsl|xlsx|gdst)}",
        "classpath*:/com/company/project/*/ruleUnderTest.rdslr" },
        ignoreRules = { "before", "after" })
public class DroolsAssertTest {

    @Rule
    public DroolsAssert drools = new DroolsAssert();

    @Test
    @AssertRules("atomic int rule")
    public void testInt() {
        drools.insertAndFire(new AtomicInteger());
        assertEquals(1, drools.getObject(AtomicInteger.class).get());
    }
}

См. rules.drl
Подробнее: https://github.com/droolsassert/droolsassert