JUnit: cómo evitar "métodos no ejecutables" en las clases de utilidades de prueba


118

Me cambié a JUnit4.4 desde JUnit3.8. Ejecuto mis pruebas usando ant, todas mis pruebas se ejecutan correctamente pero las clases de utilidad de prueba fallan con el error "No hay métodos ejecutables". El patrón que estoy usando es incluir todas las clases con el nombre * Prueba * en la carpeta de prueba.

Entiendo que el corredor no puede encontrar ningún método anotado con el atributo @Test. Pero no contienen dicha anotación porque estas clases no son pruebas. Sorprendentemente, al ejecutar estas pruebas en eclipse, no se queja de estas clases.

En JUnit3.8 no fue un problema en absoluto ya que estas clases de utilidad no extendieron TestCase por lo que el corredor no intentó ejecutarlas.

Sé que puedo excluir estas clases específicas en el destino junit en el script ant. Pero no quiero cambiar el archivo de compilación en cada nueva clase de utilidad que agregue. También puedo cambiar el nombre de las clases (pero dar buenos nombres a las clases siempre fue mi talento más débil :-))

¿Existe alguna solución elegante para este problema?


¿Tus pruebas funcionan en Eclipse / NetBeans / tu IDE favorito?
guerda

Yo uso eclipse. En realidad, no hay ningún problema allí, de alguna manera eclipse no intenta ejecutar estas clases. ¿Me pregunto cómo?
LiorH

No sé si entendimos tu pregunta. Vuelva a leer su pregunta y probablemente agregue más información.
guerda

1
@guerda: La pregunta me parece bastante clara. Su tarea Ant es encontrar clases que no contengan pruebas, porque el filtro está recogiendo la clase de utilidad. De ahí mi respuesta, que todavía creo que es totalmente relevante.
Jon Skeet

LiorH: Gracias por la aclaración, mi respuesta es un desperdicio :)
guerda

Respuestas:


50

Suponiendo que tiene el control del patrón utilizado para encontrar clases de prueba, le sugiero que lo cambie para que coincida en *Testlugar de *Test*. De esa manera TestHelperno se igualará, pero FooTestsí.


1
No creo que ayude, porque se mudó a JUnit 4.4 y eso no debería importar.
guerda

2
Parece que no entendiste el punto de mi respuesta. Tiene un filtro de nombres para determinar las clases a considerar como pruebas. Si cambia el filtro, puede excluir fácilmente las clases auxiliares.
Jon Skeet

1
Su sugerencia es válida, sin embargo, revisé mis clases de prueba y algunas comienzan con Prueba y otras terminan con Prueba. no hay una distinción clara entre clases de servicios públicos y clases de prueba reales. ¿Cree que la convención que sugirió es una buena práctica? (es decir, las utilidades comienzan con Prueba y las pruebas terminan con Prueba)
LiorH

4
Es casi una convención que agregue el sufijo * Test a las clases de casos de prueba. Es posible que deba refactorizar cambiando el nombre de las clases de prueba de manera adecuada y también cambiar el nombre de los ayudantes para que no usen esa convención de sufijo.
Spoike

2
Estoy de acuerdo con Spoike: si no puede saber por el nombre de la clase si es una prueba o un ayudante, debería cambiar el nombre de la clase. La convención es más "la clase es una prueba si y solo si termina con Prueba". Las clases de servicios públicos pueden o no comenzar con Test, no importa.
Jon Skeet

142

Anote sus clases de utilidades con @Ignore. Esto hará que JUnit no intente ejecutarlos como pruebas.


6
En realidad, no, no debería. @Ignore es para deshabilitar temporalmente las pruebas.
Alice Young

1
Lo siento, pero es una mala idea. ¿Desea comenzar a anotar su código de producción con anotaciones relacionadas con la prueba solo porque pueden coincidir con un patrón de prueba? La respuesta adecuada es arreglar los nombres de las clases si están activando la coincidencia de patrones para las pruebas. Y asegúrese de que el patrón solo encuentre clases que TERMINAN con Test. Ese es un patrón comúnmente aceptado
Kevin M

Sí, esto es malo y no me di cuenta hasta después de contribuir con otro voto positivo que no puedo eliminar. Haga que su clase base sea abstracta, luego JUnit la ignorará. Vea la respuesta de @ gmoore a continuación.
Ryan Shillington

83

Mi caso específico tiene el siguiente escenario. Nuestras pruebas

public class VenueResourceContainerTest extends BaseTixContainerTest

todos se extienden

BaseTixContainerTest

y JUnit estaba intentando ejecutar BaseTixContainerTest. El pobre BaseTixContainerTest solo estaba tratando de configurar el contenedor, configurar el cliente, pedir pizza y relajarse ... hombre.

Como se mencionó anteriormente, puede anotar la clase con

@Ignore

Pero eso hizo que JUnit informara que la prueba se omitió (en lugar de ignorarla por completo).

Tests run: 4, Failures: 0, Errors: 0, Skipped: 1

Eso me irritó un poco.

Así que hice que BaseTixContainerTest fuera abstracto, y ahora JUnit realmente lo ignora.

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0

7
Mucho mejor que@Ignore
neworld

Probé el enfoque @Ignore y pensé, bueno, eso es bueno, luego leí esta respuesta y me di una palmada en la frente, "¡Por supuesto !"
dnuttle

38

Para evitar que JUnit cree una instancia de su clase base de prueba, simplemente hágalo

public abstract class MyTestBaseClass { ... whatever... }

(@Ignore lo informa como ignorado, que reservo para pruebas ignoradas temporalmente ).


3
Los corredores de JUnit a menudo también intentan crear instancias de clases abstractas y luego fallan con un error de instanciación.
Holly Cummins

Funciona perfectamente para mis clases de prueba base
ruX

3
Esto funciona por el nombre (no termina en Prueba), no por el modificador abstracto. Cambie el nombre de la clase a MyBaseClassTest e intentará crear una instancia como lo menciona @HollyCummins (y fallará)
Hutch

En mi caso, debería serlo protected abstract class.
Mystic Lin

18
  1. Si esta es su clase de prueba base, por ejemplo, AbstractTest y todas sus pruebas amplían esto, defina esta clase como abstracta
  2. Si es de la clase Util, es mejor eliminar * Test de la clase y cambiar el nombre es MyTestUtil o Utils, etc.

10

Tenga cuidado al usar la finalización de código de un IDE para agregar la importación para @Test .

Tiene que ser import org.junit.Testy no import org.testng.annotations.Test, por ejemplo. Si hace lo último, obtendrá el error "no hay métodos ejecutables".


Esto debería ser un comentario más que una respuesta.
Swaranga Sarma

3
No veo por qué. Es una solucion valida.
Sridhar Sarnobat

4
¡Intellij Idea 2017 estaba jugando con mi mente al importar en su org.junit.jupiter.api.Testlugar! pero gracias a ti se resuelve ahora
AmiNadimi

Muchas gracias, estaba confundido al obtener el problema "no hay métodos ejecutables".
Peter S.

7

Ant ahora viene con el skipNonTestsatributo que fue diseñado para hacer exactamente lo que parece estar buscando. No es necesario cambiar sus clases base para abstraerlas o agregarles anotaciones.


2
Parece que el skipNonTestsatributo solo está disponible en ant 1.9+, lo cual es una pena, ya que parece increíblemente útil. También excluirá las superclases de prueba abstractas.
Holly Cummins

4

¿Qué hay de agregar un método de prueba vacío a estas clases?

public void avoidAnnoyingErrorMessageWhenRunningTestsInAnt() {
    assertTrue(true); // do nothing;
}

8
pero eso aumenta falsamente el número de pruebas que tenemos :) no es que sea un gran problema
Sudarshan

1

En su clase de prueba si escribió import org.junit.jupiter.api.Test; elimínelo y escriba import org.junit.Test; En este caso también me funcionó.


1
sorprendentemente, funcionó. Ejecuté manualmente en la línea de comandos de Windows. Sin embargo, otro problema es que @BeforeAll, y @AfterAllno se ejecutan.
BingLi224

aparentemente, JUnit4 funcionó (con @BeforeClassy @AfterClass, pero JUnit5 no. Referencia: junit.org/junit5/docs/current/user-guide/#migrating-from-junit4
BingLi224

0

También me enfrentaba a un problema similar ("no hay métodos ejecutables ...") al ejecutar la pieza de código más simple (Usando @Test, @Before, etc.) y no encontré la solución en ninguna parte. Estaba usando Junit4 y Eclipse SDK versión 4.1.2. Resolví mi problema usando el último Eclipse SDK 4.2.2. Espero que esto ayude a las personas que luchan con un problema similar.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.