c# - unitarias - UnitTest ¿cómo organizas tus archivos de prueba?

unit test c# ejemplo

Question

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.

¿Lo haces de la misma manera o tienes 1 clase de evaluación por clase? ¿Cómo organizas toda tu prueba?

Answer 1

Lo tenemos organizado así (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

Donde la prueba unitaria y la prueba de integración son solo los corredores de prueba, la prueba / datos contiene los archivos de datos que utilizan las pruebas de integración y prueba / tmp contiene los archivos temporales creados por las mismas pruebas y se borran para cada conjunto de pruebas.

Answer 2

Al igual que Pokus, mis pruebas están en el mismo ensamblaje que las clases para probar, así que puedo probar las internas y las privadas.

En C # tiene versiones de Debug and Release, 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í.

Answer 3

Debido a que tiendo a 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 dividen en soluciones separadas (si son más grandes)

Answer 4

En una configuración de 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

Answer 5

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.Feature
ClassnameAlpha
Nombre de clase Beta
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 contamos con un pequeño subconjunto del equipo que está usando esto 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.

Answer 6

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 burlas. 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 real. 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.

Answer 7

Mantengo las pruebas de mi unidad en un paquete dentro del proyecto que prueban. 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.

Como ejemplo (no son mis nombres de paquetes reales):

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

Answer 8

Me gusta tener mi src y las pruebas existen en el mismo paquete. Entonces organizo el mío de la siguiente manera:

src/com/company/package/Class.java
testsrc/com/company/package/ClassTest.java

Answer 9

Tengo mi clase de prueba en mi proyecto donde están las clases. De esta forma puedo probar cosas internas. Agrego postfix "Prueba" al nombre de la clase. Ejemplo: MyClass.cs será MyClassTest.cs

Answer 10

Me gusta mantenerlos cerca del código que admiten, 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.

Answer 11

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.