Actualmente, estoy dividiendo todas mis pruebas por paquete (proyectos). Entonces, si tengo 12 proyectos, crearé 1 proyecto más para Unit Test con 12 clases que probarán todo mi paquete.UnitTest ¿cómo organizas tus archivos de prueba?
¿Lo haces de la misma manera o tienes 1 clase de evaluación por clase? ¿Cómo organizas toda tu prueba?
Al igual que Pokus, mis pruebas están en el mismo ensamblaje que las clases para probar, de modo que pueda realizar pruebas internas y privadas.
En C# tiene versiones de depuración y liberación, agrego otra llamada UnitTest con una directiva de compilación UNITTEST. Luego puedo agregar la directiva (#if UNITTEST) en la parte superior de la clase de prueba, de modo que cuando compile Debug o Release, las pruebas no se compilan, pero cuando compilo UnitTest lo son.
Agrego una carpeta llamada Pruebas que contienen mis clases de prueba. Class1.cs tiene una clase de prueba Tests \ Class1UnitTest.cs.
Quizás mejores formas, pero esto funciona para mí.
lo tenemos organizado como esto (C++):
package/Class.cpp
package/Class.hpp
package/test/ClassUnitTest.cpp
package/test/ClassIntegrationTest.cpp
test/unit-test/main.cpp
test/integration-test/main.cpp
test/data
test/tmp
Dónde unidad de prueba y la integración de la prueba son sólo los corredores de la prueba, prueba/datos mantiene archivos de datos que se utilizan mediante las pruebas de integración y test/tmp contiene archivos temporales creados por las mismas pruebas y se borran para cada conjunto de pruebas.
Como suelo hacer TDD, tengo una clase de prueba para cada clase, y agrupo esas clases de prueba en una directa para una coincidencia de proyecto de prueba con un proyecto real. Dependiendo del tamaño de la solución, los proyectos de prueba existen en la misma solución (si son pequeños) o se descomponen en soluciones separadas (si son más grandes)
Guardo las pruebas de mi unidad en un paquete dentro del proyecto que evalúan . De esta forma, todas las pruebas se controlan con el código de la aplicación. El directorio de prueba de la unidad es básicamente un espejo del directorio de origen, por lo que la estructura del paquete es idéntica entre los dos.
A modo de ejemplo (no es mi nombre de paquetes real):
src.com.app
src.com.app.model
src.com.app.view
src.com.app.controller
tests.com.app
tests.com.app.model
tests.com.app.view
tests.com.app.controller
En un entorno Java/Maven:
project/src/main/java/Package/Class.java
project/src/test/java/Package/ClassTest.java
project/src/main/resources/Package/resource.properties
project/src/test/resources/Package/test_resource.properties
Maven es excelente para ayudar a facilitar la coherencia con la estructura del proyecto, que incluye cómo estructurar las pruebas de su unidad. – rich
Tiendo a tener mi proyecto estructurado project/src/package y project/testcases/package con los recursos en los mismos directorios, pero vine a Maven desde Eclipse y no al revés. Maven me permite reemplazar los directorios fuente a mi estructura de todos modos. –
@Michael: básicamente todo es posible con maven. Pero queríamos una separación clara entre los recursos y la fuente (tenemos muchos recursos). No digo que una forma sea mejor que la otra. Simplemente elegimos de esta manera. – boutta
tengo mi clase de prueba en mi proyecto donde la clase son. De esta forma puedo probar cosas internas. Agrego postfix "Prueba" al nombre de la clase. Ejemplo: MyClass.cs será MyClassTest.cs
Hacemos montajes de prueba uno-a-uno (C#). Para cada ensamblaje en una solución, tenemos un proyecto de prueba correspondiente. Cada proyecto tiene una prueba para cada clase en el proyecto correspondiente.
Por ejemplo:
Company.Product.Característica
ClassnameAlpha
ClassnameBeta
ClassnameDelta
Company.Product.Feature.UnitTests
ClassnameAlphaTests
ClassnameBetaTests
ClassnameDeltaTests
Tomo lo que xando hace un poco más. En lugar de usar las configuraciones predeterminadas de depuración/liberación, tengo una configuración para cada una de las ramas que usamos para configuraciones de compilación en Team Foundation Server. Entonces, tengo Desarrollo, Integración y Producción. Sin entrar en detalles aburridos y aburridos, las pruebas unitarias están diseñadas para las configuraciones de Desarrollo e Integración. Se incluyen en la rama Producción, pero no se compilan con la compilación. La razón por la que están incluidos es para cuando tenemos que derivar fuera de Producción (una revisión, por ejemplo) las pruebas unitarias pueden ejecutarse, modificarse e integrarse inversamente con el código modificado.
Actualmente, solo tenemos un pequeño subconjunto del equipo que lo usa en este momento, ya que estamos en el proceso de migración desde un producto heredado y un sistema de control de versiones, pero hasta ahora funciona bien. El aspecto de prueba de la unidad funciona especialmente bien, hasta ahora.
Me gusta tener mi src y las pruebas existen en el mismo paquete. Así que organizo el mío de la siguiente manera:
src/com/company/package/Class.java
testsrc/com/company/package/ClassTest.java
Los guardo en un paquete separado para todo el producto. No me gusta complicar el código de producción con el código de prueba de la unidad.
Company/Product/Package1 Company/Product/PackageN Company/Product/UnitTest/Package1/Class/Method1Fixture.cs Company/Product/UnitTest/Package1/Class/MethodNFixture.cs Company/Product/UnitTest/PackageN/Class/Method1Fixture.cs Company/Product/UnitTest/PackageN/Class/MethodNFixture.cs
Todos mis métodos son declarados públicos virtuales, yo también uso burla. Por supuesto, esto proviene principalmente del hecho de que, por lo general, los paquetes que estoy probando son las capas de datos y la lógica de negocios, por lo que rara vez tienen algún método interno verdadero. Pero tengo algunos proyectos que tienen métodos "internos". Para aquellos, si se trata de un código interno de la compañía, entonces usar el público para todos los métodos no es un problema. Creo que si no quiere que todos los métodos sean públicos, puede usar ensamblajes fuertemente nombrados y configurarlos para que el ensamblaje de prueba de unidad pueda acceder a los métodos internos. En ese momento, tengo un ensamble de prueba de unidad única que contendrá todos los accesorios de prueba para todo el proyecto.
Me gusta guardarlos cerca del código soportan, generalmente en un subdirectorio separado. De esa forma puedo hacer que compilen con el código, lo que los hace visibles; esto es importante en los proyectos heredados cuando solo unos pocos componentes tienen pruebas unitarias.
.../component/src/
/include/
/doc/
/bin/
/test/
Generalmente tenemos una suite por binario, pero esto tiene excepciones. Podemos ejecutar todas las pruebas bajo cualquier directorio con un simple comando.
La regla de oro es tener pruebas unitarias fáciles de encontrar, fáciles de compilar y fáciles de ejecutar para que no se interpongan en el camino.
Tengo mi prueba organizada por categoría de prueba. Si tengo todo el archivo de prueba de mi unidad en 1 directorio. Toda la integración en 1 directorio. Tengo todas las pruebas de persistencia en otro.Todas las carpetas tienen muchos archivos para cada cosa similar para probar.
Creo que haré eso. Buena idea –
Esto es incluso más fácil cuando cambia la plantilla del proyecto o crea la suya propia, de modo que la configuración de compilación UnitTest ya está allí. – xando
Muy inteligente. Acabo de leer todas las sugerencias y adoptaré las suyas. Gracias. –