subensamble subensamblaje hacer flexible ensamble definicion como .net unit-testing

.net - hacer - subensamblaje flexible solidworks



¿Cómo permito que el ensamblaje(prueba de la unidad uno) acceda a las propiedades internas de otro ensamblaje? (5)

Me gustaría que mi ensamblaje Core no exponga una cierta clase y todavía me gustaría poder probarlo. Cómo puedo hacer eso ?

Con InternalsVisible si sus ensamblajes son fuertemente nombrados, debe especificar la clave pública (nota: la clave completa, no la clave pública, por ejemplo) ...

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("BoardEx_BusinessObjects.Tests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100fb3a2d8 etc etc")]

y el siguiente truco es realmente útil para obtener la clave pública sin recurrir a la línea de cmd ...

http://www.andrewconnell.com/blog/archive/2006/09/15/4587.aspx

Puede usar la reflexión (como lo hacen los elementos de la prueba MS), o puede declarar al ensamblaje de prueba un amigo del ensamblaje central.

La otra opción es colocar las pruebas unitarias en el mismo conjunto.

Puse mis pruebas unitarias en el mismo ensamblaje que el código que está probando. Esto tiene sentido para mí, porque pienso en "ponte a prueba" como una característica de una clase, junto con cosas como "iniciarte a ti mismo" y "describerte a ti mismo".

He escuchado algunas objeciones a este enfoque, pero pocas han sido convincentes.

¡Duele el rendimiento Bah, digo! ¡No optimice sin datos duros! Quizás si está planeando que sus ensamblajes se descarguen a través de enlaces lentos, entonces valdría la pena minimizar el tamaño de ensamblaje.

Es un riesgo de seguridad . Solo si tienes secretos en tus pruebas. No hagas eso.

Ahora, tu situación es diferente a la mía, así que tal vez tenga sentido para ti, y tal vez no sea así. Tendrás que descubrirlo tú mismo.

Aparte: en C #, una vez intenté poner mis pruebas unitarias en una clase llamada "Pruebas" que estaba anidada dentro de la clase que estaba probando. Esto hizo obvia la correcta organización de las cosas. También evitó la duplicación de nombres que ocurre cuando las pruebas para la clase "Foo" están en una clase llamada "FooTests". Sin embargo, los marcos de prueba de la unidad a los que tenía acceso se negaron a aceptar pruebas que no fueron marcadas como "públicas". Esto significa que la clase que está probando no puede ser "privada". No puedo pensar en ninguna buena razón para exigir que las pruebas sean "públicas", ya que nadie realmente las llama como métodos públicos, todo es a través de la reflexión. Si alguna vez escribes un marco de prueba unitaria para .Net, considera permitir pruebas no públicas, ¡por mi bien!

Sugeriría que no vaya a tales problemas ... si realmente quiere probar sus clases "internas", simplemente ocultélas en un espacio de nombres que solo su código interno terminaría usando. A menos que esté escribiendo un marco en la escala de .NET Framework, realmente no necesita ese nivel de ocultamiento.