¿Qué tan lejos debe aplicar TDD?

Question

Veo el beneficio de TDD, y estoy tratando de aprender cómo rodearlo. También estoy leyendo más sobre DDD y quiero comenzar a aplicar ambos a mis proyectos de software.

He comprado algunos libros de programación "prácticos" (me refiero a los que hablan de una aplicación del mundo real con soluciones reales en lugar de pequeños fragmentos) y me he dado cuenta de que normalmente comienzan a definir la capa de "infraestructura" de la aplicación en la primera moda de código tradicional, en contraposición al uso de TDD; ambos libros se esfuerzan por discutir qué tan bueno es el TDD y cómo lo utilizará el estudio de caso.

Por ejemplo, en uno de los libros, ASP.NET 3.5 redes sociales, todo el segundo capítulo se desarrolla una clase de registro de envoltura, una clase de correo electrónico envoltura, envoltura de caché y sesión de clases (y sus interfaces asociadas) todo esto sin tocar en una prueba de unidad individual. Otro libro, .NET Domain Driven Design with C#: Problem, Design, Solution hace algo similar, y crea una clase base y un framework de repositorio con código primero antes de siquiera tocar el código "real".

Entiendo que debe probar la lógica real y la funcionalidad de sus clases de dominio. Creí que el código "no probar tuberías" solo se aplicaba al código que no escribiste (por ejemplo, clases incorporadas de .NET), pero lo que estoy leyendo parece indicar/sugerir que solo debes probar el código eso realmente tiene que ver con su aplicación y no con la fontanería que usted escribe para proporcionar una base.

¿Es esta una forma aceptable de aplicar TDD?

Answer 1

Probablemente dependa de otros factores sobre cómo planea construir su proyecto.

Si está siguiendo otras prácticas ágiles, como pequeñas iteraciones y entregas, entonces no tendrá mucha arquitectura o infraestructura al principio, porque no tendrá tiempo para desarrollar mucho mientras esté implementando y entregando las primeras características. De todos modos, ¿por qué pasar tiempo en Big Design Up Front, cuando realmente no sabes qué va a necesitar el código?

Por lo tanto, compilará su código primero y en varias iteraciones. La cobertura de prueba significa que puede refactorizar para mejorar su diseño, lo que (en teoría) permite exactamente el correcto surgimiento de la infraestructura para la aplicación tal como existe en cualquier momento en el tiempo. Ron Jeffries explains it well here. Sin las pruebas, es probable que llegues a un punto en el que necesites detenerte y descubrir cuál debe ser la estructura, lo que tomará tiempo que podría emplearse para construir funciones útiles y que vas a tener que prueba al final de todos modos.

Si está 100% seguro de que puede trazar el diseño correctamente antes de escribir cualquier código, entonces es su elección hacerlo. Sin embargo, asegúrese de dejar suficiente tiempo en el proyecto para realizar pruebas. Creo que todos deberían construir al menos un trabajo importante tanto por el proceso "tradicional" de Waterfall como por el simple hecho de sumergirse y codificarse para tener alguna experiencia que ponga las prácticas de Agile en contexto. De lo contrario, corre el riesgo de saber "qué" sin saber "por qué", y eso hace que las lecciones sean más difíciles de aprender.

Answer 2

No soy ningún experto aquí.

Pero si está desarrollando componentes de plomería, debe probarse.
Si entiendo correctamente, con TDD, el código escrito contra la interfaz & en ausencia de componentes de plomería, las personas usan objetos Mock.

Answer 3

Me metí en esto con algo de longitud en another question. Básicamente, el objetivo de usar TDD, burlarse y todo eso es desarrollar más confianza.

Answer 4

Al aprender TDD, aplique todo. Después, aplique lo que necesita.

Answer 5

Si está escribiendo las cañerías desde cero, entonces debe tener pruebas al respecto. Si solo está usando algunas interfaces y clases para abstraer sus llamadas a linq2sql entonces, no, yo no necesariamente pondría pruebas de unidad alrededor de eso.

Para citar a alguien más inteligente que yo:

No soy religioso sobre TDD. Yo lo considero una disciplina que vale siguiente. No escribo todas mis pruebas primero. Un pequeño número de ellos es simplemente más conveniente para escribir después de el código. Incluso hay algún código I que no escribe pruebas para nada, porque simplemente no lo vale. Pero esas son excepciones de a la regla. La vasta mayoría del código que escribo, primero escribo la prueba .

-Tío Bob Martin a través de: http://www.infoq.com/news/2009/02/spolsky-vs-uncle-bob

Answer 6

TDD se debe aplicar a cualquier código que se desarrollan. Cuando usa TDD no necesita probar todo, es decir, el objetivo no es una cobertura del 100%, pero la cobertura debería ser bastante alta con respecto al código que desarrolla. Por ejemplo, no necesita probar gettor/settors automáticos en C# - puede confiar en que el idioma hará su trabajo allí. Sin embargo, cuando tenga dudas, escriba la prueba primero.

Answer 7

Escriba todos primero con código para obtener experiencia con una plataforma; solo sea valiente y deséchelo una vez que esté seguro de que puede abordar la mayoría de las tareas en esa plataforma. Lo acabo de hacer con un pequeño programa Java que he comenzado.
Ahora que he adquirido experiencia, puedo ver lo que tengo que hacer para obtener una cobertura de línea muy alta ahora que empiezo a escribirla primero, incluso la mayoría de las tuberías.

Answer 8

Si prueba algún código, y no prueba otro código, ¿qué código tendrá los errores?

Sugerencia: es el código no probado.