Pruebas basadas en el diseño: Pruebas más inteligentes, no más difíciles

Opiniones de los lectores

Las críticas de 'Design Driven Testing: Test Smarter, Not Harder' son variadas, con algunos lectores que elogian sus ideas sobre la metodología de pruebas y otros que lo critican por ser un ataque sesgado contra el desarrollo dirigido por pruebas (TDD). Mientras que algunos consideran que el libro es un recurso útil que aporta claridad y ejemplos prácticos, otros creen que carece de sustancia, que promociona otros trabajos de los autores y que contiene inexactitudes sobre TDD.

Los lectores apreciaron la nueva perspectiva del libro sobre metodologías de pruebas, en particular su énfasis en las pruebas dirigidas por el diseño (DDT) sobre el desarrollo tradicional dirigido por pruebas (TDD). El estilo de redacción destaca por ser claro y conciso, con ejemplos prácticos que ayudan a comprender los conceptos. Algunos lo consideran un recurso útil para mejorar las técnicas de prueba en el desarrollo de software.

Los críticos sostienen que el libro descarta el TDD sin una comprensión adecuada y está lleno de inexactitudes sobre las metodologías ágiles. Algunos consideran que es material promocional de los propios productos de los autores, en particular ICONIX, en lugar de una exploración justa de TDD. Además, el libro presupone la familiaridad con ciertas herramientas y obras anteriores, lo que puede limitar su accesibilidad a un público más amplio. Varios críticos calificaron el contenido de repetitivo y árido.

(basado en 11 opiniones de lectores)

Título original:

Design Driven Testing: Test Smarter, Not Harder

Contenido del libro:

En este capítulo hemos ilustrado cómo realizar pruebas unitarias a partir de un diseño de software, identificando escenarios de prueba de forma sistemática que garanticen que el código está cubierto en todos los lugares adecuados. También hemos ilustrado el uso de "servicios de acrobacias" y objetos simulados para aislar el código que se está probando; por último, hemos hablado de cómo realizar pruebas unitarias más profundas en código algorítmico que puede beneficiarse de pruebas más detalladas.

¿Existe alguna forma de obtener el 95% de los beneficios de las pruebas unitarias exhaustivas que hemos realizado en este capítulo con un número significativamente menor de pruebas? En el próximo capítulo, mostraremos cómo hacer exactamente eso con las pruebas de controlador. Como verás, las pruebas unitarias tienen su lugar, pero las pruebas de controlador a menudo pueden representar un enfoque más inteligente y estructurado para las pruebas de aplicaciones. 136 C A P Í T U L O 6: DISEÑO CONCEPTUAL Y PRUEBAS DE CONTROLADOR Diseño conceptual y pruebas de controlador Como viste en el capítulo 5, las pruebas unitarias no tienen por qué implicar cubrir exhaustivamente cada línea de código, o incluso cada método, con pruebas.

Existe una ley de rendimientos decrecientes -y de dificultad creciente- a medida que se aumenta el percentil de cobertura de código. Dando un paso atrás y observando el diseño en una escala más amplia, es posible seleccionar las áreas clave del código que actúan como puntos de entrada/salida, y centrar las pruebas en esas áreas.