¿Por qué debería usar Test Driven Development? [duplicar]

Question

Duplicar:

• ¿Por qué debería practicar Test Driven Development y cómo debo comenzar?

Para un desarrollador que no conoce el desarrollo impulsado por pruebas, ¿qué problema (s) se resolverá al adoptar TDD?

[EDIT] Supongamos que el desarrollador ya (ab) utiliza un marco de prueba de unidad.

Answer 1

Aquí hay tres razones por las que TDD podría ayudar a un desarrollador / equipo:

• Mejor comprensión de lo que vas a escribir
• Aplica un poco mejor la política de escribir pruebas
• acelera el desarrollo

Una razón para escribir las pruebas primero es tener una mejor comprensión del código real antes de escribirlo. Para mí, este es el principal beneficio del desarrollo basado en pruebas. Cuando escribe los casos de prueba primero, piensa más críticamente sobre los casos de esquina. Entonces es más fácil abordarlos cuando escribe el código y se asegura de que sean precisos.

Otra razón es forzar la escritura de las pruebas. A menudo, cuando las personas realizan pruebas unitarias sin el TDD, tienen un marco de prueba configurado, escriben un código nuevo y luego se retiran. Piensan que el código ya funciona bien, entonces ¿por qué escribir pruebas? Es lo suficientemente simple como para que no se rompa, ¿verdad? Pero ahora ha perdido las ventajas de hacer pruebas de unidad en primer lugar (discusión completamente diferente). Escríbelos primero, y ya están allí.

Escribir estas pruebas primero podría significar que no es necesario iniciar el programa en un entorno de depuración (lento, especialmente para proyectos más grandes) para probar si algunas cosas pequeñas funcionan. Por supuesto, no hay excusa para no hacerlo antes de realizar cambios.

Convencer a ti mismo oa otras personas para que escriban las pruebas primero puede ser difícil. Es posible que tenga más suerte haciendo que escriban ambos al mismo tiempo, lo que puede ser igual de beneficioso.

Answer 2

Es de suponer que prueba el código que ha escrito antes de enviarlo a un repositorio.

Si eso no es cierto, tienes otros problemas con los que lidiar.

Si es cierto, puedes mirar las pruebas de escritura utilizando un marco como una forma de automatizar las rutinas o controladores principales que escribes actualmente para que puedas ejecutarlos todos de forma automática con solo presionar un botón. No tiene que pasar por encima de la salida para decidir si la prueba se aprobó o no; incrusta el éxito o el fracaso de la prueba en el código y obtiene una decisión de aprobación o rechazo de inmediato. La ejecución de todas las pruebas a la vez reduce las posibilidades de que un " golpee un topo " situación en la que arreglas algo en una clase y rompes algo más. Todas las pruebas tienen que pasar.

Suena bien hasta ahora, ¿sí?

La gente de TDD simplemente va un paso más allá al exigirle que escriba la prueba PRIMERO antes de escribir la clase. Falla, por supuesto, porque no has escrito la clase. Es su forma de garantizar que escribas clases de prueba.

Si ya está utilizando un marco de prueba, está obteniendo un buen valor de las pruebas que escribe y tiene una cobertura de código significativa de alrededor del 70%, entonces creo que lo está haciendo bien. No estoy seguro de que TDD le dé mucho más valor. Depende de usted decidir si va o no esa milla extra. Personalmente, no lo hago. Escribo pruebas después de la clase y refactorizo ??si siento la necesidad. Algunas personas pueden encontrar útil escribir primero la prueba sabiendo que va a fallar, pero yo no.

Answer 3

(Esto es más un comentario que concuerda con la respuesta de Duffymo que con una respuesta propia).

duffymo responde:

  

La gente de TDD simplemente va un paso más allá al exigirle que escriba la prueba PRIMERO antes de escribir la clase. Falla, por supuesto, porque no has escrito la clase. Es su forma de garantizar que escribas clases de prueba.

Creo que en realidad es forzar a los programadores a pensar qué está haciendo su código. Tener que pensar en una prueba hace que uno considere lo que se supone que debe hacer el código: cuáles son las condiciones previas y posteriores, qué funciones son primitivas y cuáles se componen de funciones primitivas, cuál es la interfaz pública mínima necesaria y qué un detalle de implementación.

Estas son todas las cosas en las que pienso habitualmente, así que, como usted, " prueba primero " no agrega mucho, para mí . Y francamente (sé que esto es una herejía en algunos círculos) me gusta " anclar " las ideas centrales de una clase trazando primero la interfaz pública; de esa manera puedo mirarlo, usarlo mentalmente y ver si está tan limpio como pensé que era. (Una clase o una biblioteca deben ser fáciles e intuitivas para el uso de los programadores clientes).

En otras palabras, hago lo que TDD intenta asegurar que ocurra al escribir primero las pruebas, pero como Duffymo, llego allí de una manera diferente.

Y el punto real de " prueba primero " Es conseguir un programador para hacer una pausa y pensar como un diseñador. Es una tontería hacer un fetiche de cómo el programador entra en ese estado; para aquellos que no lo hacen de forma natural, " prueba primero " Sirve de ritual para llegar hasta allí. Para aquellos que lo hacen, " prueba primero " no agrega mucho, y puede interferir con la forma habitual de los programadores de llegar a ese estado.

Una vez más, queremos ver los resultados, no los rituales. Si un chico menor necesita un ritual, una " estaciones de la cruz " o un rosario * para " meterse en la ranura " ;, " probar primero " Sirve ese propósito. Si alguien tiene su propio camino, también está bien.

Tenga en cuenta que no estoy diciendo que el código no deba ser probado. Debería. Nos da una red de seguridad, que a su vez nos permite concentrar nuestra atención en escribir un buen código, incluso el código audaz , porque sabemos que la red está ahí para detectar errores.

Todo lo que estoy diciendo es que la insistencia fetichista en " prueba primero " confunde el método (uno de muchos) con el objetivo , haciendo que el programador piense en lo que está codificando.

* Para ser ecuménico, señalaré que tanto los católicos como los musulmanes usan rosarios. Y, de nuevo, es una forma de memoria muscular mecánica para ponerse en cierto estado de ánimo. Es un fetiche (en el sentido original de un objeto mágico, no el "significado fetiche sexual") o el encanto de la buena suerte. Así que está diciendo "Om mani padme hum", o sentado en un zazen, o acariciando una "suerte" pie de conejo, (No es tan afortunado para el conejo.) El filósofo Jerry Fodor, cuando piensa en problemas difíciles, tiene un ritual similar: se repite a sí mismo, "Vamos, Jerry, ¡puedes hacerlo!" (También lo intenté, pero como mi nombre no es Jerry, no funcionó para mí.))

Answer 4

Idealmente:

No perderá tiempo escribiendo características que no necesita. Tendrá un completo conjunto de pruebas de unidades que servirá como red de seguridad para la refactorización. Tendrá ejemplos ejecutables de cómo su código está destinado a ser utilizado. Su flujo de desarrollo será más suave y rápido; pasarás menos tiempo en el depurador.

Pero sobre todo, su diseño será mejor. Su código se factorizará mejor, se acoplará de manera flexible, será altamente cohesivo y se formará mejor. Métodos y amp; clases.

Answer 5

Para mi proyecto actual (que se ejecuta en un proceso relativamente pesado), he adoptado una forma peculiar de TDD que consiste en escribir casos de prueba de esqueleto basados ??en documentos de requisitos y maquetas de GUI. Escribo docenas, a veces cientos de ellas antes de comenzar a implementar cualquier cosa (esto se ejecuta totalmente contra " pure " TDD, que dice que debes escribir algunas pruebas y luego comenzar de inmediato con una implementación de esqueleto).

He encontrado que esta es una excelente manera de revisar los documentos de requisitos. Tengo que pensar en el comportamiento descrito en ellos mucho más intensamente que si solo fuera a leerlos. En consecuencia, encuentro muchas más inconsistencias y lagunas que de otra manera solo habría encontrado durante la implementación. De esta manera, puedo solicitar una aclaración antes y tener mejores requisitos cuando comienzo a implementar.

Luego, durante la implementación, las pruebas son una forma de medir qué tan lejos debo llegar. Y me impiden olvidar cualquier cosa (no te rías, eso es un problema real cuando trabajas en casos de uso más grandes).

Y la moraleja es: incluso cuando su proceso de desarrollo no es realmente compatible con TDD, todavía se puede hacer de una manera, y mejorar la calidad y la productividad.

Answer 6

Personalmente no uso TDD, pero uno de los mayores profesionales que puedo ver con la metodología es la garantía de satisfacción del cliente . Básicamente, la idea es que los pasos de su proceso de desarrollo son los siguientes:

1) Hable con el cliente sobre lo que se supone que debe hacer la aplicación y cómo se supone que reacciona ante diferentes situaciones.

2) Convierta el resultado de 1) en Pruebas unitarias, cada una de las cuales prueba una característica o escenario.

3) Escribe simple, " descuidado " Código que (apenas) pasa las pruebas. Cuando termine, habrá cumplido con las expectativas de sus clientes.

4) Refactoriza el código que escribiste en 3) hasta que creas que lo has hecho de la manera más efectiva posible.

Cuando se hace esto, se espera que haya producido un código de alta calidad que satisfaga las necesidades de sus clientes. Si el cliente ahora quiere una nueva función, comienza el ciclo otra vez: discuta la característica, escriba una prueba que se asegure de que funcione, escriba el código que pasa la prueba, refactorice.

Y como han dicho otros, cada vez que ejecutas tus pruebas, te aseguras de que el código anterior aún funciona y de que puedes agregar una nueva funcionalidad sin romper el antiguo.

Answer 7

La mayoría de las personas con las que he hablado no usan un modelo TDD completo. Por lo general, encuentran el mejor modelo de prueba que funciona para ellos. Encuentra el tuyo con TDD y encuentra dónde eres más productivo.

Answer 8

Hice un gran esfuerzo para aprender TDD para el desarrollo de Ruby on Rails. Pasaron varios días antes de que realmente me metiera en eso. Era muy escéptico, pero hice el esfuerzo porque los programadores que respeto lo apoyan.

En este punto siento que definitivamente valió la pena el esfuerzo. Hay varios beneficios que estoy seguro que a otros les complacerá enumerar. Para mí, la ventaja más importante es que ayuda a evitar esa situación de pesadilla al final de un proyecto en el que algo se rompe repentinamente sin motivo aparente y luego pasa un día y medio con el depurador. Ayuda a evitar que su base de código se deteriore a medida que le agrega más y más lógica.

Answer 9

TDD (Test Driven Development / Design) ofrece las siguientes ventajas

• le asegura que conoce los criterios de aceptación de la tarjeta de historia antes de comenzar
• le asegura que sabe cuándo dejar de codificar (es decir, cuando se cumplen los criterios de aceptación, por lo tanto, se evita la comercialización de oro)

Como resultado, terminas con un código que es

1. verificable
2. diseño limpio
3. poder ser refaccionado con confianza
4. el código mínimo necesario para satisfacer la tarjeta de la historia
5. una especificación viva de cómo funciona el código
6. capaz de soportar un ritmo sostenible de nuevas características

Answer 10

Es de conocimiento general que escribir pruebas y tener una gran cantidad de pruebas automatizadas son una buena cosa.

Sin embargo, sin TDD, a menudo se vuelve tedioso. La gente escribe las pruebas y luego las deja, y las pruebas no se actualizan como deberían, ni las nuevas funciones se prueban con la frecuencia que deberían.

Una gran parte de esto se debe a que el código se ha convertido en una molestia para probar. TDD influirá en su diseño, por lo que es mucho más fácil probar . Debido a que ha usado TDD, tiene un buen número de pruebas, lo que hace que sea mucho más fácil encontrar regresiones cada vez que cambian su código o sus requisitos, simplificando la depuración dramáticamente, provocando una buena evaluación de TDD y alentando que se escriban más pruebas cuando se realizan cambios. Necesitamos, y estamos de vuelta al inicio del ciclo.

Answer 11

Hay muchas ventajas:

• Calidad de código superior
• Menos errores
• Menos tiempo perdido

Cualquiera de esos solo sería una justificación suficiente para implementar TDD.