¿Cómo puedo especificar dependencias de prueba JUnit?

Nuestro kit de herramientas tiene más de 15000 JUnit pruebas, y se sabe que muchas pruebas fallan si falla alguna otra prueba. Por ejemplo, si el método X.foo() utiliza la funcionalidad de Y.bar() y YTest.testBar() falla, entonces XTest.testFoo() también fallará. Obviamente, XTest.testFoo() también puede fallar debido a problemas específicos de X.foo().¿Cómo puedo especificar dependencias de prueba JUnit?

Si bien esto está bien y todavía quiero que se ejecuten ambas pruebas, sería bueno si se pudiera anotar una dependencia de prueba con XTest.testFoo() apuntando a YTest.testBar(). De esta manera, uno podría ver inmediatamente qué funcionalidad utilizada por X.foo() también está fallando, y qué no.

¿Existe tal anotación disponible en JUnit o en otro lugar? Algo así como:

public XTest { 

    @Test 
    @DependsOn(method=org.example.tests.YTest#testBar) 
    public void testFoo() { 
    // Assert.something(); 
    } 

}

Fuente

2010-04-06 Egon Willighagen

Es un hilo de la vejez, sin embargo: Si X.foo() utiliza Y.bar() La prueba debe simulacro Y.bar(), de lo contrario (!) su prueba no es una prueba unitaria (sino una prueba de integración). La idea de las pruebas unitarias es no tener ninguna dependencia. Sin embargo, estoy aquí por una razón ;-) – letmejustfixthat

JExample y TestNG tienen algo por el estilo.

No sé qué tan útil es, pero si lo intenta, vuelva a informarnos si fue útil.

Fuente

2010-04-06 12:09:26

Sí, parece un excelente comienzo: http://chem-bla-ics.blogspot.com/2010/08/specifying-unit-test-dependencies-with. html –

Es útil en situación cuando ClassA.methodA() invoca ClassB.methodB() y ambos toman mucho tiempo. En este caso, puede especificar que testMethodA() depende de testMethodB(), es decir, si testMethodB() falla, testMethodA() también falla ** sin ejecución **. – Cherry

@Cherry: Parece una excusa para no escribir [pruebas rápidas] (http://agileinaflash.blogspot.fi/2009/02/first.html). Algunas opciones para mejorar el diseño: (1) hacer que el método B sea rápido, (2) hacer que el método A no dependa del método B, (3), usar un doble de prueba para ClassB al probar ClassA. –

~~Realmente no hay algo como esto que yo sepa.~~ (Editar: aprendes algo nuevo todos los días :)) En mi opinión, esto no es tan malo (aunque puedo ver que es útil, especialmente cuando se usa para otras formas de pruebas automatizadas, por ejemplo, pruebas de integración). Sus pruebas, IMO, no están en el sentido más estricto de la palabra "pruebas unitarias" (al menos no la prueba para X#foo()). Las pruebas para X#foo() deben tener éxito o fallan según solo en la implementación de X#foo(). No debe depender de Y#foo().

Lo que haría en su posición es burlar Y, e implementar algo como MockY#foo() con un comportamiento muy simple y controlado, y usarlo en las pruebas de X#foo().

Dicho esto, con 15,000 pruebas, puedo ver cómo esto sería un dolor para refactorizar. :)

Fuente

2010-04-06 12:11:48

No veo por qué las pruebas unitarias no pueden tener dependencias ... nuestro toolkit define objetos de datos y algoritmos ... si un objeto de datos falla, ¿cómo lo haces? ¿esperar que el algoritmo corrija automágicamente para eso? Tal vez el nombramiento de ambos métodos foo() fue engañoso ... –

Solo las pruebas simuladas estrictas no mostrarían ninguna dependencia entre ellas (y aún así pueden ...). En general, tales dependencias siempre son posibles y deben reflejar las dependencias en el diseño OO. Creo que mantener dicha anotación en todas las pruebas aumentaría la complejidad sin un beneficio significativo, pero puede ser beneficioso tener dicha anotación en algunos casos centrales. – topchef

Puede declarar test dependencies in TestNG, la sintaxis es casi la misma que en su ejemplo. No creo que JUnit ofrezca algo similar.

Fuente

2010-04-06 12:12:05

https://github.com/junit-team/junit.contrib/tree/master/assumes – jplandrain

En behavior driven design biblioteca jBehave hay una palabra clave GivenScenarios que importa una lista de escenarios que se ejecutan antes del escenario principal. Esto le da la oportunidad de definir dependencias y tener un punto de falla. El registro de jBehave le dirá si la prueba falla en las dependencias o en la sección del cuerpo principal.

Fuente

2010-04-06 12:15:46

Hay una contribución a JUnit que se ocupan de esto: https://github.com/junit-team/junit.contrib/tree/master/assumes

Fuente

2011-10-28 02:31:41

Bien, bien! Espero que se fusione pronto :) –

Esto parece que todavía no está disponible en maven central (ver http://search.maven.org/#search%7Cga%7C1%7Cjunit-contrib). ¿Como lo usas? ¿O usas algo más ahora? – koppor

org.junit.FixMethodOrder

@FixMethodOrder (MethodSorters.NAME_ASCENDING) Esto va en la parte superior de su clase de prueba Unidad.

puede asignar nombres a los métodos public void step1_methodName etc

Fuente

2014-12-26 07:27:56

¿Cómo puedo especificar dependencias de prueba JUnit?

Respuesta

Cuestiones relacionadas