C++ y TDD adecuado

Question

¡Hola! Hace poco intenté desarrollar un proyecto de tamaño pequeño en C# y durante todo el proyecto, nuestro equipo utilizó la técnica Test-Driven-Development (TDD) (xunit, moq).

Realmente creo que esto fue increíble, porque (cuando se combina con C#) este enfoque permite relajar al codificar, relajarse al proyectar y relajarse al refacturar. Sospecho que todo esto TDD -stuff realmente simplifica el proceso de codificación y, bueno, permitió (eventualmente, para mí) obtener el mismo resultado con menos células cerebrales funcionando.

Justo después de eso he intentado usar TDD emparejado con C++ (utilicé Google Test y Google Mock bibliotecas), y, no sé por qué, pero en realidad creo que TDD aquí fue un paso atrás en términos de desarrollo rápido de aplicaciones.

Tuve algunos momentos en los que tuve que pasar grandes cantidades de tiempo pensando en mis pruebas, creando burlas, reconstruyéndolas y maldiciendo mi monitor.

Y, bueno, obviamente no puedo preguntar algo como "lo que hice mal?" o "¿qué estuvo mal en mi enfoque?", porque no sé qué describir. Pero si hay personas que están acostumbradas a TDD en C++ (y, probablemente, C#) también, podrían recomendarme cómo hacerlo correctamente.

Recomendaciones de marco, enfoques de arquitectura, consejos de codificación simple: si tiene experiencia en TDD & C++, responda.

Answer 1

Creo que TDD es mucho más difícil de hacer en C++ que C#.La falta de reflexión y la renuencia común (ya menudo bien justificada) a confiar en el polimorfismo dinámico (interfaces y herencia) en comparación con el polimorfismo estático hace que sea más difícil burlarse de muchas clases.

Existen algunos frameworks de pruebas unitarias extremadamente inteligentes para C++, pero lo inteligente es que tratan de eludir las limitaciones del lenguaje.

TDD funciona mejor en idiomas dinámicos. Es una excelente manera de trabajar en Python. Es posible en C# (que no es dinámico, pero tiene capacidades de reflexión exhaustivas)

En C++, a menudo es problemático. Eso no significa que no pueda, o no deba hacerse, pero cuando lo haga, tendrá que trabajar un poco más duro. Y a veces, es mejor que uses otro enfoque por completo.

Answer 2

Pruebe la más fácil - CxxTest.

Answer 3

TDD es algo que requiere cierta práctica para hacerlo bien, independientemente de la plataforma. Lo que algunas personas no parecen darse cuenta es que la naturaleza del problema que intenta resolver puede tener un gran impacto en la facilidad con la que puede aplicar TDD a la solución. He tenido problemas en el pasado cuando sabía la solución a la que quería avanzar, pero era extremadamente difícil descubrir cómo resolver el problema de una manera que parecía ajustarse al modelo TDD. Ahora bien, hay varias razones por las que esto puede suceder, y es imposible decir cuál es la forma "correcta" de manejar esa situación.

En este punto, mi primera reacción ante este tipo de problema es volver a examinar mis suposiciones originales sobre el problema. ¿Lo estoy haciendo más complejo de lo necesario? ¿Estoy tratando de escribir pruebas para llegar a un diseño que ya he decidido en lugar de dejar que las pruebas guíen el diseño? ¿Es solo un problema funky, y tengo que aceptar que el enfoque típico de TDD no va a funcionar en este caso?

Para una discusión interesante de esto puede mirar this blog post de Uncle Bob Martin, donde habla de un intento de Ron Jeffries por create a Sudoku Solver using TDD, y realmente no funciona. Ahora, debido a que este intento no produjo una buena solución, no significa que el TDD sea inútil, simplemente significa que el problema que se está resolviendo es más complejo y no se presta al enfoque de diseño emergente de TDD.

Answer 4

Creo que el desarrollo impulsado por pruebas es muy difícil de realizar correctamente todo el tiempo; a veces las pruebas simplemente fluyen, a veces se requiere un poco de un salto. Para mantener las cosas rápido, con frecuencia me alejo del enfoque TDD. Eso no es un problema para mí, ya que mantengo un conjunto completo de pruebas unitarias para todo el código que he 'completado' (permitiendo la relajación mientras codifico los nuevos bits y refactorizando).