Unidad/Organización de prueba de integración en una solución grande de Visual Studio

Question

Estoy comenzando a desarrollar y organizar pruebas para una gran solución de Visual Studio. (Sí, sé que las pruebas deberían haberse desarrollado junto con el código en lugar de cuando el proyecto está casi completo, pero las cosas son lo que son).

He visto preguntas similares sobre la organización de pruebas unitarias en soluciones de Visual Studio , pero tampoco vi ninguna que aborde las pruebas de integración. Agradecería una guía sobre dónde ubicar los proyectos de prueba para que no llenen la ya de por sí gran base de códigos.

Aquí está la jerarquía básica de cosas dentro de la solución. (Todos los artículos no terminan en .proj son carpetas dentro de un proyecto o carpetas solución.)

• HardwareServices
  • HardwareService1
    • HardwareService1.Core.proj
    • HardwareService1.Host.proj
    • HardwareService1.Service.proj
  • HardwareService2
    • HardwareService2.Core.proj
    • HardwareService2.Host.proj
    • HardwareService2.Service.proj
• Infraestructura
  • MyApp.Database.proj
  • MyApp.Infrastructure .proj
  • MyApp.ReportViewer.proj
  • MyApp.SettingsManager.proj
• AppModules
  • AppModule1.proj
    • Común
    • Informes
    • Servicios
    • ViewModels
    • Vistas
  • AppModule2.proj (estructura similar a otros AppModules)
  • AppModule3.proj (estructura similar a otros AppModules)
• Módulos
  • ComputeEngine.proj
  • Footer.proj
  • Header.proj
  • CommonServices.proj

Mi idea era hacer una carpeta de soluciones llamadas "pruebas" y luego imitar la jerarquía superior, haciendo una prueba de proyecto para cada proyecto de código de producción. Dentro de cada proyecto de prueba, crearía carpetas llamadas "UnitTests" y "IntegrationTests".

Mi objetivo es crear un esquema de nombres/organización coherente para que no exista ambigüedad acerca de dónde deberían ir las nuevas pruebas y dónde encontrar las pruebas existentes. Dado el gran tamaño de este proyecto/aplicación, me gustaría obtener la estructura bastante sólida desde la puerta para que no sea un problema después.

Gracias por su tiempo y consejo.

Answer 1

La convención de nomenclatura que nuestra empresa adoptó fue el uso de projectName.Tests.Unit y projectName.Tests.Integration.

Con su estructura existente que tener algo como esto:

• HardwareService1
  • HardwareService1.Core.proj
  • HardwareService1.Host.proj
  • HardwareService1.Service.proj
  • Pruebas
    • HardwareService1.Core .Tests.Unit
    • HardwareService1.Core.Tests.Integration

Si mantener su carpeta de pruebas junto con la carpeta raíz que no tiene que imitar la estructura completa de nuevo como el las pruebas son correctas con el proyecto respectivo.

nota al margen

Al tener el nombre del proyecto que tiene una constante Tests.Unit que ayuda a ayudar en la ejecución de pruebas unitarias en su escritura de la estructura como se puede ejecutar pruebas con una búsqueda comodín como **\*tests.unit*.dll

Al final del día, la estructura del proyecto puede ser muy subjetiva, así que haga lo que tenga sentido en su entorno y tenga sentido para su equipo.