Usar burlas durante las pruebas ¿vale la pena el esfuerzo?

Question

Durante este semestre mi profesor intentó convencernos de por qué es bueno usar pruebas unitarias durante el desarrollo, por qué es bueno validar los datos (Bloque de aplicaciones de Microsoft) y también nos habló sobre el uso de burlas (RhinoMocks) para probar nuestros métodos cuando no teníamos acceso a una base de datos.

Tuve que hacer algunas pruebas unitarias con burlas y para que funcionasen tuve que crear a mano la jerarquía de objetos que se necesitaba para probar mi método (Me tomó un tiempo escribir todo lo que necesitaba) .

La pregunta que quiero hacer: en producción, ¿es útil usar burla? ¿Debo usarlo cada vez que tenga la oportunidad? Y también el esfuerzo realizado para escribir todo con el fin de probar un método con burlas ¿vale la pena?

agradecimiento

Answer 1

Sí, usando objetos simulados como uno entre sus muchas herramientas de prueba unitaria definitivamente son un esfuerzo que vale la pena.

Sin embargo, va mejor con Desarrollo basado en prueba porque las pruebas controlan el diseño. Cuando comienzas a sentir el dolor de código estrechamente acoplado porque tienes que mantener las estructuras profundamente anidadas, sabes que es hora de refactorizar a una API más débilmente acoplada.

Answer 2

NO hay anwser derecho a éste. Los marcos de burla (como RhinoMocks) pueden hacer algunas cosas poderosas. Mi elección personal es que me gusta rodar mis propios objetos simulados. Si encuentro esto difícil lo uso como un olor que tengo algo mal en mi diseño.

Utilizo simulacros en el código heredado cuando es muy difícil o hay muchos códigos para configurar mis pruebas unitarias.

Acepto que hay más que podría aprender sobre el uso de marcos de burla.

Answer 3

Para mi proyecto actual, todavía escribo objetos de código auxiliar para las pruebas de mi unidad la mayor parte del tiempo. Solo una vez que realmente sentí la necesidad de un objeto simulado y lo escribí de forma manual.

Me gustaría aconsejar llevar esto de manera muy pragmática: si necesita mucho simulacro de objetos, considere aprender un marco de burla (esto también viene con un precio, por supuesto); de lo contrario, use objetos de talón o su mano ocasional- escrito simulacro de objeto

Answer 4

Mocks resolver los siguientes problemas:

• Sin ellos sus pruebas terminan prueba más de su código bajo prueba . Así que si hay un error en la dependencia que se marcan hasta en su prueba (o lo que es peor, puede encubrir un error en su código)
• Los puntos de integración pueden volver resultados diferentes en el momento de escribir pruebas en comparación con el tiempo de las pruebas se ejecutan debido a un cambio externa dependencia (piensa - cambio en el estado de base de datos)
• Cuando la integración con sistemas externos sus pruebas se ejecutarán mucho más lenta .Esto hará que otros desarrolladores ejecutar con menos frecuencia y, por tanto, disminuir el valor de sus pruebas
• Cuando se usan correctamente hacen pruebas más sencillo de leer y la intención de su módulo más evidente.

Answer 5

No estoy seguro de si RhinoMocks tiene la misma capacidad pero con moq puede obtener lo que necesita de una jerarquía de objetos sin tener que crearlo realmente.

Ie. Si su método acepta un IUser y necesita obtener acceso a IUser.Person.ContactInfo.PhoneNumbers.BusinessPhone, no necesita crear todo el gráfico. Solo necesita hacer esto:

var mockUser = new Mock(); mockUser.Setup (u => u.Person.ContactInfo.PhoneNumbers.BusinessPhone) .Returns ("555-1212");

Esto puede ser valioso pero también puede dar lugar a un diseño deficiente como el mencionado anteriormente.