Tengo una clase con un método público Send()y algunos métodos privados. Llama a un par de servicios web y procesa la respuesta. El procesamiento se realiza en métodos privados.
Quiero probar el código de la unidad. Según tengo entendido, las pruebas unitarias deberían probar mi código de forma aislada (es decir, simular las respuestas del proveedor).
También creo que los métodos privados no deberían necesitar una unidad de prueba. Pero si solo pruebo el método Send (), mi código no se prueba de forma aislada y depende de la respuesta del proveedor.
¿Debería hacer públicos mis métodos privados para poder probarlos con respuestas simuladas? Parece una mala práctica ya que solo la clase debería llamarlos.
Disculpas si es una pregunta básica, soy bastante nuevo en las pruebas unitarias.
Estoy usando C # y VS2010
fuente
Respuestas:
Debe separar el código que se ocupa de los servicios web (es decir, enviar y recibir datos) del código que procesa los resultados. Mueva el último código a una clase distinta, haciendo públicos los métodos necesarios. Luego, puede probar fácilmente la lógica de procesamiento de la unidad, aislada de las dependencias externas.
Con esto, también hace que su código se ajuste al Principio de responsabilidad única . Como regla general, sentir la necesidad de probar métodos privados es a menudo una indicación de que la clase tiene demasiadas responsabilidades, por lo tanto, debe refactorizarse en varias clases.
fuente
Creo que una prueba con tales dependencias ( llamar a los proveedores de servicios web ) es una prueba de integración en lugar de una prueba unitaria.
fuente
Como han dicho otros, si sus pruebas unitarias tienen dependencias externas como servicios web o llamadas a la base de datos, entonces NO son pruebas unitarias, son pruebas de integración.
Las pruebas unitarias verdaderas pueden ejecutarse independientemente de los componentes externos, aparte del componente que se pretende probar y deben ser repetibles independientemente del entorno. Si los servicios web externos se caen, la prueba de su unidad no debe fallar.
Lo solucionamos utilizando un marco de simulación. Los objetos simulados nos permiten crear un simulacro de un componente para que el componente en nuestra prueba de unidad utilice estos objetos simulados en lugar de los reales. Podemos inyectar objetos simulados en el componente comprobable y especificar qué argumento (s) estamos esperando, qué nos gustaría que devolviera cuando se llama, incluso qué excepción nos gustaría que arrojara. Le recomiendo leer más sobre el tema, ya que mejorará la confiabilidad e independencia de sus pruebas unitarias.
Para una buena publicación en diferentes marcos de burla de C #, consulte el siguiente hilo SO:
/programming/37359/what-c-mocking-framework-to-use
EDITAR: Para los extremadamente sensibles, reconoceré que no mencioné DbUnit u otras herramientas transaccionales que pueden revertir los cambios en la base de datos al final de la prueba. Estos también son repetibles y pueden ser independientes del entorno con los datos de prueba generados, por lo que no se necesita un marco de simulación en este caso.
fuente