Desarrollo basado en pruebas - me convence! [cerrado]

Question

Sé que algunas personas son partidarios masivas de desarrollo basado en pruebas. He utilizado las pruebas de unidad en el pasado, pero sólo para las operaciones de prueba que se pueden probar fácilmente o que creo que va a ser muy posiblemente correcta. completas sonidos completos o cerca de cobertura de código como se tardaría mucho tiempo.

1. ¿Qué proyectos se utiliza desarrollo basado en pruebas para? Cómo se lo utiliza solamente para los proyectos por encima de un cierto tamaño?
2. ¿Debo utilizar o no? convencerme!

Answer 1

Ok, algunas ventajas de TDD:

1. Esto significa que usted termina con más pruebas. todos gustos tiene pruebas, pero pocas personas como escrito ellos. La construcción de prueba de escritura en sus medios de flujo de desarrollo que termina con más pruebas.
2. Escribir en un fuerzas de ensayo que podría hacerle a la capacidad de prueba de su diseño, y el diseño es comprobable casi siempre mejor diseño. No está del todo claro por qué esto pasa a ser el caso, pero mi experiencia y la de la mayoría de los evangelistas TDD parece tener un vistazo.
3. Aquí está un estudio diciendo que aunque TDD tarda un poco más a la escritura, hay una buena rentabilidad de la inversión debido a que obtiene el código de mayor calidad, y por lo tanto menos errores de arreglar.
4. Se le da confianza en la refactorización. Es una gran sensación de ser capaz de cambiar un sistema sin tener que preocuparse acerca de romper todo lo demás porque está bastante bien cubierto por las pruebas unitarias.
5. Casi nunca se obtiene un error de repetición, ya que cada uno que encuentre debe hacerse una prueba antes de que llegue una solución.

Se pedirá que estar convencido, por lo que estos eran los beneficios. Ver esta pregunta para una visión más equilibrada.

Answer 2

Robert C. Martin hizo originalmente estos puntos - puedo realizar copias de seguridad de mi propia experiencia:

• Usted va a construir automáticamente un conjunto de pruebas de regresión de las pruebas de unidad a medida que avanza.
• Usted casi nunca se gastará tiempo de depuración, como si el código en un agujero, es más fácil para deshacer el código para el momento en que la última prueba se ha superado, en lugar de abrir una grieta en un depurador.
• Cada pocos minutos se compruebe que funciona su código -. Toda la actividad (o al menos todas del comportamiento cubierto por las pruebas, que si está haciendo TDD es un porcentaje muy alto de la misma)

Me prácticamente hacer TDD todo el tiempo, si estoy trabajando en el código de producción o el juego; Me resulta difícil de codificar cualquier otra manera en estos días.

Answer 3

(Negación:. Puedo hacer casi cualquier cosa interfaz de usuario, así que no puedo hablar de TDD para interfaces de usuario)

Yo uso TDD en casi todo lo que hago, desde aplicaciones triviales a pilas enteras SIP.

Yo no uso de TDD en un sitio web legado PHP me hice cargo. Me resulta doloroso no tienen pruebas. Y me resulta sumamente molesto accidentalmente rompiendo partes del sitio, ya que no tengo un conjunto de pruebas de regresión que me dice que se rompió algo. El cliente no tiene el presupuesto para mí (a) pruebas de escritura para el código base y (b) en el proceso de hacer que el código comprobable en el primer lugar, por lo que sólo hay que poner al día con él.

Answer 4

• Cada vez que su cliente puede ser suministrada de manera más eficaz (que posiblemente relacionarse bien con las pruebas - y lo hará al menos cortada hacia abajo en la discusión de fin de proyecto)
• Cada vez que se necesitaría más tiempo mantener sus co-desarrolladores informados sobre EVERYTYHING en el código que poner esfuerzo en la construcción de la prueba - y esto es antes de lo que puede pensar

Answer 5

¿Qué? Sin respuesta negativa!?

Renuncia: No soy anti-unidad-prueba. Cuando la gente dice TDD, supongo que quieren decir la versión que suena enfermedades en las que son pruebas de escritura antes de escribir el código para el 80-100% de todo el código que escriben.

Yo diría:

• Es un facilitador. Si la captura de problemas de regresión es un problema tan grande para usted que TDD completamente automático desde el principio parece que vale la pena, escribir pruebas hasta el último trozo de código que escribe, en realidad podría ayudar a usted ignora el verdadero problema.

• Ayuda a las personas ignoran el verdadero problema. Al fijar una bichos se convierte en un juego de golpe-a-mole, donde dos más emergente, los golpes de arquitectura. Atención. Centrarse en el problema real. Al ver los lunares antes de que debe ser whacked es aseado-o, pero que no debería estar allí en el primer lugar.

• Se alimenta de una gran cantidad de tiempo. Golpeé errores ocasionales. Yo no golpeo tantos que parece merecer la pena para prefijar cada nueva escritura cosa que con una prueba para él. cuestiones de captura, donde es probable que suceda. manejar este tipo de errores que son fáciles de diagnosticar. Validar. Prueba en puntos clave de solapamiento / cuello de botella. Pero por amor de Dios no mida hasta el último getter y setter en algo que probablemente no debería haber tenido aquellos en el primer lugar.

• Diseño de enfoque: No hay absolutamente ninguna manera, incluso un desarrollador bueno va a escribir el mejor código que pudieron cuando también se están centrando en la prueba. Si parece que la única manera de tener un diseño decente, te recomiendo ver lo anterior acerca de "centrarse en el problema real".

• Macro-Diseño Fall: El código base en mi trabajo actual está plagado de interfaces que nunca se utilizan más de una vez y masivas violaciones de principio DRY básica que sólo finalmente empecé a entender cuando me di cuenta de la gente escribía para el prueba-marcos y las pruebas en general. Las pruebas no deberían conducir a la arquitectura estúpida. No, en serio, no hay nada que de alguna manera es más escalable o empresa digna trata de copiar y pegar 20 archivos y sólo realizar cambios significativos en dos de ellos. La idea es que las preocupaciones por separado, no partirlos por la mitad. Cruft y la abstracción sin sentido que le costará más que no tiene una cobertura del 95% nunca lo hará.

• Es muy popular y mucha gente muy, muy parecido. Si eso no es una razón suficiente para al menos la segunda conjetura y / o veterinario a la mierda de cualquier tecnología antes de su aprobación, que aprender un poco de paranoia.