¿El proveedor de una interfaz también debe proporcionar una implementación simulada para las pruebas?

Perdimos mucho tiempo en nuestra última prueba de integración en un error que creo que debería haberse encontrado en las pruebas unitarias. El problema fue que una interfaz / servicio que llamamos se comportó de manera diferente de lo que esperábamos y la prueba unitaria no encontró este problema porque nos burlamos de esa interfaz para la prueba unitaria y nuestra simulación se basó en nuestra interpretación errónea de lo que la interfaz haría hacer. Ahora podría estar un poco enojado con nuestro querido compañero de trabajo que proporcionó la interfaz, porque su descripción / especificación (un breve comentario de JavaDoc) fue ambigua y contribuyó a nuestro malentendido. Por otro lado, pensé que el problema podría haberse evitado si esos mismos compañeros de trabajo hubieran proporcionado una implementación simulada de su interfaz que podríamos llamar en nuestras pruebas unitarias.

Ahora, ¿cuál es la mejor práctica para organizar la creación de objetos simulados entre los equipos que proporcionan y usan interfaces compartidas? Cuales son tus experiencias

design unit-testing organization

— Robert Jack Will
fuente

Espero que en toda esta investigación de la culpa hayas incluido algo para ti mismo por no preguntarle al autor si entendiste que era correcto ... Una pregunta de tu parte podría haber ahorrado todo el dolor.

— Walter

Walter, gracias por tus ediciones y comentarios constructivos. Su sugerencia no responde la pregunta directamente, pero de hecho es una solución al problema original que tengo. Como me resulta muy difícil hacer buenas preguntas sobre la propia comprensión, se me ocurrió otra idea: podríamos haber pedido al otro equipo que revisara nuestro plan para usar su interfaz y podrían haber detectado el problema.

— Robert Jack Will

Respuestas:

Idealmente, si.

Cualquiera que escriba código que otras personas usen no está obligado a proporcionar nada que complemente el código. Sin embargo, si usted quiere que la gente use su código (y todo el mundo siempre debe ser escrito con esta mentalidad), extensa documentación pertinente - que puede incluir ejemplos - son extremadamente útiles.

Creo que nunca he leído documentación y he pensado: "Esto es estúpido; hay demasiada documentación". Las personas son naturalmente dotadas para saltarse lo que consideran innecesario. Sin embargo, no podemos simplemente leer la mente e interpolar la documentación o conceptos que no han sido explicados. Por lo tanto, es seguro suponer: no existe demasiada buena documentación. También debe suponer que la persona que lo lee es un bebé ingenuo (es decir, que sea lo más simple posible).

Los ejemplos sobre cómo crear instancias y usar una clase siempre son útiles. Aunque, si el código se basa demasiado en la documentación para ser entendido, ese es otro problema (separado).

Esta respuesta no debe verse como una potencia de fuego que justificará gritarle a su compañero de trabajo. Es simplemente una pauta de lo que creo que es beneficioso y debe hacerse. Si bien esto es completamente inútil en su situación (aunque, creo que su pregunta es básicamente una queja), lo mejor que puede hacer es dar el ejemplo y esperar que su colega aparezca.

— JK
fuente

Mientras me he encontrado a mí mismo quejándose de demasiada documentación, esos casos han sido raros (y estaba tomando cuestión más con la calidad que dio lugar a muy largo redactado y confundiendo docs).

— Tim Post

@Tim: Gracias, acabo de editar, me refería a una buena documentación. ¡Desafortunadamente, cualquiera puede escribir un montón de basura como 'documentación'!

— JK

¿El proveedor de una interfaz también debe proporcionar una implementación simulada para las pruebas?

No , pero el proveedor también debe proporcionar el código fuente para sus pruebas unitarias. Al leer estas pruebas unitarias, obtendrá una buena impresión de cómo se debe utilizar la biblioteca. Tal vez pueda agregar pruebas unitarias a las pruebas de proveedor para especificar lo que espera del proveedor.

Existen muchas herramientas / marcos de simulación que pueden implementar un falso / trozo / simulación.

Pedirle al proveedor una implementación simulada no tiene una buena relación costo / beneficio porque no puede saber qué parte de la implementación falsa debe ser casi idéntica a la implementación real y qué parte es solo fachada.

Otra forma de evitar esto es si el proveedor usa contratos de código para asegurarse de que la lib se usa de la manera especificada.

— k3b
fuente

+1 "Existen muchas herramientas / marcos de burla que pueden implementar un falso / trozo / simulación".

— Armand

Pruebas unitarias: veo dos problemas al usarlos como documentación: 1. solo muestran ejemplos de lo que el servicio admite, pero no me dicen si se admite un determinado uso que tengo en mente. 2. Leer las pruebas unitarias es tan exigente / agotador como leer códigos y estoy buscando una solución que ahorre trabajo a todos. Estoy buscando algo que funcione automáticamente, como pruebas o contratos (que también estamos investigando).

— Robert Jack Will

"El proveedor no puede conocer el uso del simulacro": no estoy seguro de eso. Por un lado, el simulacro debe verificar todas las condiciones previas (es el servicio utilizado correctamente) y debe devolver algunos valores ficticios. Básicamente, todo lo que se necesita para probar la unidad de un cliente. ¿Podría dar más detalles sobre qué información le falta al proveedor para hacer esto bien?

— Robert Jack Will

the mock should check all the preconditions: ¿por qué el simulacro necesita verificar si la lib real hace esta comprobación? Si tiene pruebas de integración con la biblioteca real, estas pruebas lo llevarán al problema.

— k3b

k3b: queremos encontrar errores lo antes posible y la prueba de integración puede ser mucho más tarde. Este fue exactamente el problema que tuvimos. Bueno, ya estamos trabajando para mejorar el proceso para que las pruebas de integración puedan realizarse antes y con mayor frecuencia, pero aún así las pruebas unitarias deberían encontrar tantos errores como sea posible.

— Robert Jack Will