Drools pruebas con JUnit

Question

¿Cuál es la mejor práctica la normativa Drools prueba con JUnit?

Hasta ahora hemos usado JUnit con DBUnit a reglas de prueba. Tuvimos datos de la muestra que se puso a hsqldb. Tuvimos par de paquetes de reglas y para el final del proyecto, es muy difícil hacer una buena entrada de prueba para probar ciertas reglas y no de fuego otros.

Así que la pregunta exacta es que ¿cómo puedo limitar las pruebas de JUnit a uno o más cierta regla (s) para la prueba?

Answer 1

Personalmente utilizo pruebas de unidad para probar reglas aisladas. Creo que no hay nada demasiado malo en ello, siempre y cuando no caigan en una falsa sensación de seguridad que su base de conocimientos está trabajando porque las reglas aisladas están trabajando. Prueba de toda la base de conocimiento es más importante.

Puede escribir las pruebas de aislamiento con AgendaFilter y 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.

Código fuente: http : //blog.athico.com/2007/07/my-rules-dont-work-as-expected-what-can.html

Answer 2

I creó la biblioteca simple que ayuda a escribir pruebas unitarias para Drools. Una de las características es exactamente lo que necesita: declarar determinados archivos drl que desea utilizar para su prueba de unidad:

@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());
    }
}

Para más detalles tienen un aspecto en el poste blog: http://maciejwalkowiak.pl/blog/2013/11/24/jboss-drools-unit-testing-with-junit-drools/

Answer 3

No trate de ejecución de la regla límite a una sola regla para una prueba. A diferencia de clases OO, reglas individuales no son independientes de otras normas, por lo que no tiene sentido probar una regla en el aislamiento de la misma manera que lo haría probar una sola clase utilizando una prueba de unidad. En otras palabras, para poner a prueba una sola regla, prueba que tiene el efecto deseado en combinación con las otras normas.

En su lugar, ejecutar pruebas con una pequeña cantidad de datos sobre todas las reglas, es decir, con un número mínimo de hechos en la sesión de reglas, y la prueba de los resultados y tal vez eso fue despedido una regla en particular. El resultado no es en realidad muy diferente de lo que tiene en mente, porque un conjunto mínimo de datos de prueba sólo se puede activar una o dos reglas.

En cuanto a los datos de la muestra, yo prefiero usar datos estáticos y definir los datos de prueba mínimos para cada prueba. Hay varias maneras de hacer esto, pero mediante programación la creación de objetos de datos en Java podría ser lo suficientemente bueno.

Answer 4

Una unidad de prueba con DBUnit no funciona muy bien. Una prueba de integración con DBUnit hace. Este es el por qué: - Una unidad de prueba debe ser rápido. - base de datos de un DBUnit restauración es lenta. Tarda 30 segundos con facilidad. - Una aplicación en el mundo real tiene muchas columnas no nulas. Por lo tanto, los datos aislados de una sola característica, todavía utiliza fácilmente la mitad de las tablas de la base de datos. - prueba de la unidad A debe ser aislado. - Restauración de la base de datos DBUnit para cada prueba para mantenerlos aislado tiene inconvenientes: --- Ejecución de todas las pruebas toma horas (sobre todo porque la aplicación crece), para que nadie los ejecuta, por lo que constantemente se rompen, por lo que son discapacitados, así que no hay pruebas, por lo que la aplicación está llena de errores. --- La creación de una base de datos media por cada unidad de prueba es un montón de trabajo de creación, una gran cantidad de trabajos de mantenimiento, puede convertirse fácilmente en no válido (con respecto a la validación de esquema de base de datos que no son compatibles, consulte Hibernate Validator) y suele exhibir hace una mala trabajo de representar la realidad.

En su lugar, las pruebas de integración de escritura con DBUnit: - Una DBUnit, el mismo para todas las pruebas. Cargarlo sólo una vez (incluso si se ejecuta 500 pruebas). - Wrap cada prueba en una transacción y deshacer la base de datos después de cada prueba. La mayoría de los métodos utilizan la propagación requiere de todos modos. Establece sólo la sucia testdata (para restablecerlo en el siguiente examen si hay una próxima prueba) sólo cuando la propagación es REQUIRES_NEW. - Rellenar la base de datos con casos de esquina. No agregue los casos más comunes que son estrictamente necesarios para probar sus reglas de negocio, por lo que suele exhibir sólo 2 casos comunes (para poder probar "uno a muchos"). - prueba de futuro pruebas de escritura: - No pruebe el número de reglas activadas o el número de hechos insertados. - En cambio, si se prueba un hecho cierto insertada está presente en el resultado. Filtrar el resultado en un determinado conjunto de propiedades a X (diferente del valor común de que la propiedad) y probar la serie de datos insertados con ese conjunto de propiedad a X.

Answer 5

¿Por qué no elegir mismo enfoque que tenemos para el código Java con las pruebas unitarias y de integración? Unidad de prueba se trata de tomar pedazo mínimo de código y probar todos los casos de uso posibles que definen las especificaciones. Con la integración a prueba su objetivo es que no todos los casos de uso posibles, pero la integración de varias unidades que en conjunto el trabajo. Hacer lo mismo con las reglas. Segregar las reglas de negocio significado y propósito. Más simple 'unidad bajo la prueba' podría ser archivo con simple o conjunto se requiere alta cohension de reglas y lo que para que funcione (si lo hay), como archivo de definición de DSL común y tabla de decisiones. Para prueba de integración que podría tomar subconjunto significativo o todas las reglas del sistema.

Con este enfoque tendrá muchas pruebas unitarias aisladas, los cuales no se verán afectadas y no requerirá el apoyo cuando se agrega nuevas reglas, ya que tendrá conjunto aislado de reglas de negocio con subconjunto de datos de entrada para probar respectivos escenarios de negocio. Y tendrá pocas pruebas de integración con cantidad limitada de datos de entrada común a reproducir y prueba 'escenarios comunes'. La adición de nuevas normas a prueba de integración requerirá a la salida de la prueba de actualización y reflejará cómo las nuevas reglas de flujo de datos comunes impacto.

regla de prueba unitaria que le da la posibilidad a los recursos de carga en declarativa forma y las reglas de aserción activa realmente. Se preservará errores de aserción interiores y reportar cualquier reglas de activación de desajuste que pistas sobre lo que salió mal en un vistazo. cobertizos de registro de luz sobre las relaciones causa-efecto entre los acontecimientos. Funciona con SpringRunner.class para las pruebas de integración primavera.

Ejemplo:

@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
Más: https://github.com/droolsassert/droolsassert