2010-06-30 20 views
40

de clases en MyClass.java prueba JUnit alternativas de nombre de caso de prueba:convención de nomenclatura JUnit sufijo o prefijo prueba

TestMyClass.java 
MyClassTest.java 

http://moreunit.sourceforge.net parece utilizar "Prueba" como prefijo por defecto, pero he visto ambos usos. Ambos parecen ser reconocidos cuando se ejecuta todo el proyecto como prueba unitaria en eclipse, ya que es la anotación dentro de las clases las que se analizan para @Test. Creo que maven hace lo mismo.

¿Cuál es preferido?

Respuesta

72

Otro argumento a favor de sufijo - al menos en el idioma Inglés:

una clase por lo general representa un sustantivo, es un modelo de un concepto. Una instancia de una de sus pruebas sería una 'Prueba de Mi Clase'. Por el contrario, un método modelaría algún tipo de acción, como 'test [the] calculate [method]'.

Debido a esto, yo siempre uso el sufijo 'para las clases de prueba y el prefijo para los métodos de prueba:

the MyClass test   --> MyClassTest 
test the calculate method --> testCalculate() 
+0

Cómo hacer esto desde el punto de vista del diseño era lo que estaba buscando. – aron

46

Prefiero usar el sufijo, lo que significa que mirar la lista de archivos en un directorio es más simple: no tiene que ignorar mentalmente las primeras cuatro letras para llegar a algo significativo. (Supongo que ya tiene las pruebas en un directorio diferente al código de producción).

También significa que cuando usa Open Type (Ctrl-T) en Eclipse, termina viendo el código de producción y su prueba, al mismo tiempo ... que es también un recordatorio si no ve una clase de prueba :)

6

Antes de JUnit 4 era común para nombrar sus clases de prueba y luego ejecutar SomethingTest JUnit en todas las clases que coincidan con *Test.java. En estos días, JUnit 4 impulsado por la anotación, solo necesita anotar sus métodos de prueba con @Test y terminarlo. Es probable que sus clases de prueba estén bajo una estructura de directorio diferente a su fuente real (fuente en src/ clases de prueba en test/) por lo que estos prefijos/sufijos son en gran medida irrelevantes.

+9

No lo son. Supongamos que tenemos un modelo para un conector y esta clase se llama 'Connector', que el modelo para una prueba para probar una instancia de conector sería' ConnectorTest'. Para mí eso es bastante obvio. Estás en lo cierto desde una perspectiva puramente técnica, pero nombrar debería estar relacionado con el diseño. –

+1

Iluminador para conocer la historia. +1 – aron

+0

@Andreas_D, eso es cierto. Por lo general, una clase de prueba unitaria se centrará en probar una clase Java para que la unidad pruebe que 'Connector' estará en' ConnectorTest', por lo tanto, en retrospectiva de mi respuesta, los prefijos/sufijos todavía tienen algún valor. – krock

4

No ofender a nadie, pero creo que es justo decir que "moreunit" es mucho menos conocido que JUnit, que es bastante omnipresente, y estableció la convención de las clases de prueba de sufijo "Test".

Aunque JUnit4 eliminó la necesidad de seguir las convenciones de nomenclatura de clase y método (resp. "Prueba de postfix" y "prueba de prefijo"), creo que ambas siguen siendo útiles para mayor claridad.

imaginar el horror de tener src/test/java /.../ MyClass.myMethod() probado por src/main/java /.../ MyClass.myMethod() ...

veces, es útil divergir de las convenciones de JUnit3: encuentro que nombrar métodos de configuración después de lo que hacen ("createTestFactory()") y anotarlos "@Before" es mucho más claro que el genérico "setUp()".

Esto es particularmente útil cuando se deben realizar varias acciones de configuración no relacionadas; pueden estar en métodos separados, cada una etiquetada @Before. Esto comunica la independencia de las acciones muy bien.

+2

Una gran idea de BDD (http://blog.dannorth.net/introducing-bdd): en lugar de nombrar los métodos de prueba "@Test testFailOnNull() {...}", use el verbo "should": "@Test shouldFailOnNull() {...} ". Encuentro que esto transmite mucha información de manera concisa. Evita repetir "prueba" y lee mejor que "@Test failOnNull() {...}". –

1

También uso MyClassTest_XXX cuando quiero dividir mi prueba en varias clases.Esto es útil cuando se prueba una clase grande y quiero que las pruebas se agrupen lógicamente. (No se puede controlar el código heredado para que surja este escenario). Luego tengo algo así como KitchenSinkTest_ForArray, KitchSinkTest_ForCollection, etc.

3

Prefiero usar la sintaxis TestClassName. Cuando uso la otra sintaxis, tengo problemas para identificar cuál es la prueba y cuál es la clase real en los editores cuando tengo ambos abiertos. Tener que buscar las últimas cuatro letras en el nombre es fastidioso y estas letras no siempre se muestran.

Para mí, la otra sintaxis genera varios intercambios incorrectos entre archivos todos los días y eso lleva mucho tiempo.

2

Creo que es importante que se sienta cómodo con sus pruebas si está trabajando solo. Pero si estás en un grupo, es mejor que te sientes y arregles algo. Personalmente tiendo a usar sufijo para las clases y prefijo para los métodos y trato de que mis grupos se adapten a esta convención.

0

Sugiero MyClassTests.

Las clases deben ser sintagmas nominales, por lo tanto de uso general MyClassTest y menos comunes MyClassTests o MyClassTestCase o MyClassTestFixture todo funciona. Técnicamente, una instancia de una clase de prueba JUnit representa un test fixture, pero TestFixture es un poco demasiado detallado para mí.

Creo que MyClassTests transmite la intención de la mejor manera porque normalmente hay varios métodos de prueba en una clase que representa una sola prueba (caso de prueba).

Cuestiones relacionadas