Contado por mi jefe para usar Moq y eso es todo. Me gusta, pero parece que a diferencia de MSTest o mbunit, etc ... no puede probar los métodos internosMoq ¿cómo se prueban los métodos internos?
Así que estoy obligado a hacer pública una implementación interna en mi interfaz para que pueda probarla.
¿Echo de menos algo?
¿Puedes probar métodos internos usando Moq?
Muchas gracias
Usted puede utilizar el atributo InternalsVisibleTo para hacer visibles los métodos de Moq.
Para ensamblajes de nombre seguro, necesita esto. [assembly: InternalsVisibleTo ("DynamicProxyGenAssembly2, PublicKey = 0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")] –
Si usted tiene muchos de código que no está probado por los métodos públicos, es probable que tenga código que debe ser movido a otro clases.
Como dije en otra respuesta, puede usar el atributo InternalsVisibleTo para eso. Pero eso no significa que debas hacerlo.
no es el punto de la unidad de pruebas para probar todo lo que sin embargo? Probar los métodos internos/privados podría revelar problemas que las pruebas a través de las públicas podrían no revelar. Especialmente cuando se agregan nuevas funciones públicas y usan las internas ... ¿o me falta algo? – CodeRedick
Su presunción inicial de que es necesario probar el método interno es una idea falsa común de los principiantes acerca de las pruebas unitarias.
De acuerdo, pueden existir casos en que los métodos privados se deben probar de forma aislada, pero el caso común del 99% es que los métodos privados se prueban implícitamente porque hacen que los métodos públicos pasen sus pruebas. Los métodos públicos llaman a los métodos privados.
Los métodos privados están ahí por algún motivo. Si no resultan en un comportamiento comprobable externo, entonces no los necesita.
¿Alguna de tus pruebas públicas falla si acabas de eliminarlas? Si es así, entonces ya están siendo probados. Si no, ¿por qué los necesitas? Averigüe para qué los necesita y luego exprese eso en una prueba en contra de la interfaz pública.
Un beneficio principal con TDD es que su código se vuelve fácil de cambiar. Si comienza a probar las partes internas, entonces el código se vuelve rígido y difícil de cambiar.
No hay nada de malo en hacer que las partes internas sean visibles para otras pruebas. Si necesita probar los aspectos internos de una clase, hágalo de todos modos. El hecho de que los métodos no sean públicos no significa que deba ignorarlos y probar solo los públicos. Una aplicación bien diseñada en realidad tendrá una mayoría del código encapsulado dentro de sus clases de tal manera que no sean públicas. Por lo tanto, ignorar los métodos no públicos en sus pruebas es un gran error en mi humilde opinión. Una de las ventajas de las pruebas unitarias es que prueba todas las partes de su código, sin importar cuán pequeñas y cuando sus pruebas estén funcionando al 100%, es una suposición razonable de que cuando todas estas partes se ensamblan, su la aplicación funcionará correctamente para el usuario final. Por supuesto, verificar esa última parte es donde entran las pruebas de nivel de integración, que es una discusión diferente. Entonces prueba!
InternalsVisibleTo es tu amigo para pruebas internas. Recuerde firmar sus ensamblajes y está seguro.
Desde mi punto de vista, se debe usar Mocking para simular algún tipo de comportamiento del que dependemos pero que no nos propongamos probar. Por lo tanto:
P: ¿Me falta algo? - No, no le falta nada, a MOQ le falta la capacidad de burlarse de los comportamientos privados.
P: ¿Puede probar métodos internos utilizando Moq? - Si el resultado del comportamiento privado es visible públicamente, entonces sí puede probar el método interno pero no es debido a Moq que puede probarlos. Me gustaría hacer una observación aquí es que Mock no es la capacidad de probar, sino la capacidad de comportamientos similares que no estamos probando pero de los que dependemos.
C: Un beneficio principal con TDD es que su código se vuelve fácil de cambiar. Si comienza a probar las pruebas internas, entonces el código se vuelve rígido y difícil de cambiar - No estoy de acuerdo con este comentario por 2 razones principales: 1: No es una idea errónea para principiantes, ya que TDD no solo trata de la capacidad de codificar código más rápido pero también de mejor calidad. Por lo tanto, cuanto más pruebas podemos hacer, mejor. 2: No hace que el código sea más difícil de cambiar si de alguna manera puede probar los métodos internos.
Moq no es una alternativa a MSTest o mbunit. ambos son un marco de prueba unitario, mientras que Moq es un marco de burla. aunque casi siempre se usan en conjunto, son dos cosas muy diferentes. Por cierto +1 a su jefe, Moq es excelente ;-) –