¿La unidad de prueba "utiliza" el proyecto o simplemente tiene el mismo espacio de nombres?

Antecedentes

Estoy trabajando en un proyecto con C # .NET, y acabo de agregar un nuevo proyecto de prueba unitaria a mi solución en Visual Studio. La forma en que siempre he estado haciendo esto es:

Crear un nuevo proyecto de prueba unitaria.
Haga que ese proyecto incluya una referencia al proyecto bajo prueba .
Solo incluye ( using) el proyecto.

Supongo que la otra forma en que podrías hacerlo sería ...

Crear un nuevo proyecto de prueba unitaria.
Haga que ese proyecto incluya una referencia al proyecto bajo prueba .
Haga que el proyecto de prueba de unidad comparta un espacio de nombres con el proyecto bajo prueba .

Pregunta

¿Existe una forma aceptada de hacer esto para proyectos en el mundo .NET, o es solo una opinión y no hay nada más?

— Fisgonear
fuente

Usar el mismo espacio de nombres parece una forma de terminar con conflictos de espacio de nombres. Y aún necesitaría una referencia al ensamblaje que contiene el código bajo prueba.

— David Arno

Estoy de acuerdo con David. A menos que tenga cuidado de nombrar explícitamente a sus métodos de prueba algo diferente al método bajo prueba, corre el riesgo de que haya conflictos de nombres. Simplemente no veo cómo compartir un espacio de nombres aporta algo a la fiesta.

— Robbie Dee

Si se escriben correctamente, las pruebas nunca deberían entrar en conflicto, ya que los nombres de los métodos serán algo así MethodName_StateUnderTest_ExpectedBehavior(), y estoy seguro de que podría encontrar nombres no conflictivos adecuados para las clases de prueba. La verdadera pregunta es: ¿realmente quieres que esos tipos aparezcan en tu inteligencia?

— Robert Harvey

@DavidArno TDD no es aplicable en todas las situaciones. Si todo lo que hago es ir y leer algún dispositivo electrónico y devolver un resultado (que es el 99% del tiempo para escribir un código EE) ... Lo único que me importa es si obtengo o no el valor correcto, en ese momento no importa si escribo el examen antes o después.

— Snoop

@StevieV, mis disculpas, no se suponía que fuera un comentario serio (por lo tanto, la cara sonriente), pero supongo que no fue así.

— David Arno

Respuestas:

Sus pruebas unitarias están en un proyecto separado y cumplen una función separada de su código principal, por lo que ponerlas en un espacio de nombres separado tiene más sentido para mí.

Si está considerando ponerlos en el mismo espacio de nombres solo para guardar la usinglínea, entonces no lo haga. Menos código es bueno, un código más claro es mejor.

— svick
fuente

Y no desea lanzar / distribuir / implementar pruebas unitarias.

— radarbob

Poner las pruebas en un espacio de nombres separado asegura (en algunos idiomas) que está viendo la API como lo vería un consumidor externo, es decir, no acceder a miembros que solo son accesibles para las clases en el mismo espacio de nombres. Convenientemente, sus pruebas silenciarán cualquier advertencia falsa acerca de que sus miembros públicos de API no estén referenciados o estén expuestos innecesariamente.

— StackOverthrow

@TKK La pregunta es sobre C # y en C #, los espacios de nombres no funcionan así.

— svick

@svick: sí, y C # no te obliga a dar a cada ensamblado su propio espacio de nombres. Sin embargo, es una convención útil, especialmente en proyectos más grandes, y no manejaría un ensamblaje de prueba de unidad de manera diferente a cualquier otro ensamblaje en esto.

— Doc Brown

He usado proyectos de pruebas unitarias con el mismo espacio de nombres que el proyecto real (eliminando manualmente el Testssufijo en el espacio de nombres del proyecto de prueba) durante algunos años sin problemas.

Creo que conduce a un código más directo, por lo que generalmente sugiero seguir ese enfoque. Algunos de los inconvenientes, como los posibles conflictos de espacio de nombres, simplemente no deberían suceder cuando se trata de un proyecto de prueba de unidad, ya que ya está siguiendo algunas convenciones de prueba para eso, como el sufijo con todas las clases de prueba Tests. Además, me parece bastante intuitivo tener las clases y las clases de prueba en el mismo espacio de nombres.

Algunas personas pensarán que es extraño, pero este no debería ser el caso, ya que muchos ensamblados de marcos también usan esta estrategia de tener múltiples DLL que tienen clases en los mismos espacios de nombres: no se supone que sea algo sorprendente o malo. practicar en y por sí mismo.

Sin embargo, creo que este es más por gusto personal, por lo que no es realmente "responsable" per se. Dicho esto, "mi voto", según el razonamiento anterior, es probarlo usted mismo al principio, y si le gusta el enfoque, hágalo.

— julealgon
fuente