prefijos prefijo paquetes palabras nomenclatura nombres metodos con java unit-testing junit naming-conventions

java - paquetes - Convención de nombres JUnit sufijo o prefijo Prueba



palabras con des prefijo (9)

Clase bajo prueba MyClass.java JUnit nombre de caso de prueba alternativas:

TestMyClass.java MyClassTest.java

http://moreunit.sourceforge.net parece usar "Test" como prefijo predeterminado, 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?

Antes de JUnit 4 era común nombrar sus clases de prueba SomethingTest y luego ejecutar JUnit en todas las clases que coinciden con *Test.java . En estos días, JUnit 4 impulsado por anotaciones, solo necesita anotar sus métodos de prueba con @Test y terminar con esto. Sus clases de prueba probablemente estarán bajo una estructura de directorio diferente a su fuente real (fuente en src/ clases de test/ en test/ ) por lo que estos prefijos / sufijos son en gran medida irrelevantes.

Creo que es importante que te sientas cómodo con tus exámenes si trabajas 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.

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.

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

A veces, es útil apartarse de las convenciones 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.

Otro argumento para el sufijo, al menos en inglés:

Una clase generalmente representa un nombre , 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, siempre usaría 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()

Prefiero usar el sufijo, significa que mirar la lista de archivos en un directorio es más simple: no tienes 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 tanto el código de producción como su prueba al mismo tiempo ... que también es un recordatorio si no ve una clase de prueba: )

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 conduce a varios intercambios incorrectos entre archivos todos los días y eso lleva mucho tiempo.

Sugiero MyClassTests .

Las clases deben ser sintagmas nominales, por lo que comúnmente se usan MyClassTest y MyClassTest menos comunes o MyClassTestCase o MyClassTestFixture . Técnicamente, una instancia de una clase de prueba JUnit representa un accesorio de prueba , 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).

También uso MyClassTest_XXX cuando quiero dividir mi prueba en múltiples 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.