5

Recientemente he visto Integration Tests are a Scam por J. B. Rainsberger y ahora estoy buscando más material sobre el tema. Debo decir que estoy sorprendido por lo mal que lo estamos haciendo (es decir, las pruebas de integración cuando deberíamos realizar pruebas unitarias), intrigados por los conceptos descritos por Rainsberger pero también confundidos acerca de cómo aplicarlos. Me gustaría tener más de las pruebas de colaboración y pruebas de contrato descritas pero no sé por dónde empezar.Eliminando la "estafa de prueba de integración" - Comprender las pruebas de colaboración y contrato

Lo único que quedó atrapado en mi mente son las 4 preguntas de las pruebas tienen que preguntar:

Lado A:

Do I ask the right question? 
Can I deal with the answer? 

Lado B:

Can I answer a question? 
Do I answer correctly? 

¿Pero cómo aplico esto a algún método aleatorio en mi pila de aplicaciones?

¿Hay algún libro o tutorial o ejemplo que tome un ejemplo del mundo real y aplique estas ideas de micropruebas aisladas? Idealmente, el ejemplo usa Java, C# o C++.

Cualquier literatura que trate estos conceptos en general y me ayude a comprenderlos mejor será apreciada.

Además, si hay foros por ahí donde pueda hacer preguntas más detalladas sobre cómo realizar correctamente las pruebas unitarias y tal vez incluso refactorizar el código existente y publicar ejemplos sería bueno.

Gracias!

+2

Eso parece un infierno de un montón de preguntas en una sola vez. Es posible que desee reducirlo. Y tal vez (aunque otros serán más capaces de juzgar esto), esto podría ser más adecuado para los programadores SE? – Bart

+0

Sí, tienes razón.Lo limité a la pregunta sobre los recursos de información y publiqué los detalles en la sección del programador. – Pete

+0

Programadores SE de hecho –

Respuesta

3

Recomendaría xUnitTestPatterns - Refactoring Test Code by Gerald Meszaros, que proporciona algunos puntos de vista sobre sus preguntas y muchos detalles sobre lo bueno y lo malo de varias prácticas cuando se prueba a nivel de método individual.

Si ha leído Refactoring by Fowler, verá que la respuesta a sus preguntas no es necesariamente en blanco y negro, sino que se basa en la heurística de su experiencia y la de los demás.

+0

Gracias por la sugerencia. Obtuve lo mismo en los programadores SE, así que tengo un buen presentimiento sobre cómo ordenarlo. Fowler es un nombre que he escuchado mucho recientemente (leyendo "Crecimiento de software orientado a objetos guiado por pruebas" en este momento). Quizás tendré que conseguir eso también. – Pete

1

Rainsberger sobre-exagera la ineficacia de las pruebas de integración es, para probar su punto de llegar a 100% de calidad final (corrección básica) en el código

DbC se centra en la formalización de las responsabilidades y beneficios fuera de las dos partes A y B. Es como una extensión de la interfaz. Entonces, el enfoque principal se convierte en el contrato mismo, una capa en el medio que le indicaría a ambas partes si pueden interactuar entre sí.

Rainsberger dice claramente que hasta el momento no hay una biblioteca explícita o soporte de idiomas y logra tanto A mocks como B para preguntar lo mismo, insinuando que podría ser un trabajo de doctorado para alguien.

Sin embargo Jim Weirich tiene un buen ejemplo en el contrato es un OO-patrón para la prueba y para las dos partes que se comprometan a usarlo https://www.youtube.com/watch?v=7Yw744FMqTY

Cuestiones relacionadas