2011-03-01 22 views
6

En nuestro proyecto, actualmente tenemos un gran número de pruebas (junit) que se dividen en tres categorías: unidad, integración, wicket.Cómo agrupar/categorizar un gran número de pruebas JUnit

Ahora quiero agrupar estas pruebas para que pueda ejecutar solo una (o dos) de esas categorías. Lo único que encontré son conjuntos de pruebas junit y categorías como se describe aquí: http://www.wakaleo.com/component/content/article/267

Mi problema es que no quiero declarar todas las pruebas en los trajes de prueba con @SuiteClasses.

¿Hay alguna manera de agregar las clases de suite con comodines/patrones?

Respuesta

3

Puede ponerlos en diferentes paquetes. La mayoría de los IDE tienen una forma de ejecutar todas las pruebas en un paquete determinado. También es bastante simple encontrar todas las clases de prueba en un paquete con un script de shell para ejecutar pruebas como parte de una compilación o lo que sea. No sé si hay una manera de hacerlo con la hormiga, pero me lo imagino.

TestNG le permite etiquetar las pruebas como pertenecientes a grupos particulares, luego ejecutar esos grupos. ¡Parece exactamente lo que quieres, aparte del hecho de que no es JUnit!

Puede abusar del mecanismo de suposición de JUnit para hacer lo que quiera: tener una propiedad del sistema para cada grupo de pruebas, y luego comenzar cada prueba asumiendo que se ha establecido la propiedad adecuada. La ejecución de todas las pruebas ejecutará todo, pero se ignorará todo lo que no se desee.

1

¿Ha considerado usar TestNG? Esto se basa en JUnit pero mucho más potente: Consulte comparison.

Grouping es fácil.

Transformar sus pruebas de JUnit a TestNG debe ser sencillo.

Alternativamente, podría crear 3 scripts de hormiga que ejecutarán sus pruebas unitarias, pero esto es menos flexible.

+0

¿Puede explicar el por qué? -1'd esto? Usar TestNG es una buena sugerencia. –

+0

De acuerdo. TestNG es lo suficientemente maduro como para ser una caída justa en reemplazo. – serg10

+0

Tx Tom por votar nuevamente, también me gustaría saber el razonamiento detrás del voto a favor. –

2

Incluso si usa categorías JUnit, aún no podrá usar comodines/patrones ya que las categorías son anotaciones, que son tipos de Java.

Como se ha señalado por otros comentaristas, esto es exactamente por qué TestNG utiliza cadenas para definir grupos en lugar de anotaciones:

@Test(groups = { "database.ACCOUNTS", "fast-test" }) 
public void newAccountsShouldBeCreated() { ... } 

Una vez que haya definido sus grupos de esta manera, se puede incluir y excluir grupos usando expresiones regulares (por ejemplo, "base de datos. *", "front-end. *", etc ...).

TestNG no está basado en JUnit, pero es muy fácil convertir todas sus pruebas JUnit en TestNG. Aquí hay dos entradas de blog que dan una visión general del proceso:

http://beust.com/weblog/2011/01/04/one-click-test-conversions/

http://beust.com/weblog/2011/02/07/are-your-unit-tests-talking-to-each-other-behind-your-back/

4

Trate de usar ClasspathSuite

También tuve el mismo problema en el que tenía más de 5500 pruebas jUnit.Categoricé luego en 3 grupos y creé 3 suites usando la extensión jUnit anterior. Es genial.

7

Suponiendo que mi comprensión de la pregunta es correcta, en realidad se puede hacer utilizando JUnit. El código siguiente se usó con JUnit 4.11 y nos permitió dividir todas las pruebas en 2 categorías: "sin categoría" e Integración.

IntegrationTestSuite.java

/** 
* A custom JUnit runner that executes all tests from the classpath that 
* match the <code>ca.vtesc.portfolio.*Test</code> pattern 
* and marked with <code>@Category(IntegrationTestCategory.class)</code> 
* annotation. 
*/ 
@RunWith(Categories.class) 
@IncludeCategory(IntegrationTestCategory.class) 
@Suite.SuiteClasses({ IntegrationTests.class }) 
public class IntegrationTestSuite { 
} 

@RunWith(ClasspathSuite.class) 
@ClasspathSuite.ClassnameFilters({ "ca.vtesc.portfolio.*Test" }) 
class IntegrationTests { 
} 

UnitTestSuite.java

/** 
    * A custom JUnit runner that executes all tests from the classpath that match 
    * <code>ca.vtesc.portfolio.*Test</code> pattern. 
    * <p> 
    * Classes and methods that are annotated with the 
    * <code>@Category(IntegrationTestCategory.class)</code> category are 
    * <strong>excluded</strong>. 
    */ 

@RunWith(Categories.class) 
@ExcludeCategory(IntegrationTestCategory.class) 
@Suite.SuiteClasses({ UnitTests.class }) 
public class UnitTestSuite { 
} 

@RunWith(ClasspathSuite.class) 
@ClasspathSuite.ClassnameFilters({ "ca.vtesc.portfolio.*Test" }) 
class UnitTests { 
} 

IntegrationTestCategory.java

/** 
* A marker interface for running integration tests. 
*/ 
public interface IntegrationTestCategory { 
} 

La primera prueba de muestra a continuación no está anotada con ninguna categoría, por lo que todos sus métodos de prueba se incluirán al ejecutar UnitTestSuite y se excluirán al ejecutar IntegrationTestSuite.

public class OptionsServiceImplTest { 
    @Test 
    public void testOptionAssignment() { 
     // actual test code 
    } 
} 

muestra A continuación se marca como prueba de integración en el nivel de clase que significa tanto serán excluidos sus métodos de prueba cuando se ejecuta el UnitTestSuite e incluido en IntegrationTestSuite:

@Category(IntegrationTestCategory.class) 
public class PortfolioServiceImplTest { 
    @Test 
    public void testTransfer() { 
     // actual test code 
    } 
    @Test 
    public void testQuote() { 
    } 
} 

Y la tercera muestra demos una prueba clase con un método no anotado y el otro marcado con la categoría Integración.

public class MarginServiceImplTest { 
    @Test 
    public void testPayment() { 
    } 
    @Test 
    @Category(IntegrationTestCategory.class) 
    public void testCall() { 
    } 
} 
Cuestiones relacionadas