¿Cuáles son los límites de TDD?

Question

Recientemente descubrí cuánto me gusta desarrollar código de la manera TDD: siento que tengo mucho más control sobre la dirección en que se desarrolla el desarrollo. Mientras que antes pasaba mucho tiempo diseñando estructuras de datos y algoritmos por adelantado, ahora empiezo de a poco y "hago crecer" mi código de forma orgánica. Después de cada ciclo rojo/verde/refactor tengo código que hace algo. Siento que mi código es algo vivo y estoy dirigiendo hacia dónde debería crecer. No sé si así es como todos se sienten cuando entran en TDD, pero esta es mi experiencia. Y me sorprende que esto sea tan similar al éxito de los proyectos de software libre en lugar de diseñarlos.

Sin embargo, ahora que tengo un problema con el desarrollo basado en pruebas, estoy empezando a preguntarme cuáles son sus límites. Parece ser bastante útil para desarrollar código funcional: alimente esta entrada a esa función, y obtendrá este resultado. Pero esto es solo una pequeña parte de lo que trata el desarrollo de software. ¿Qué hay de desarrollo de GUI, redes, desarrollo de bases de datos, aplicaciones web? ¿Cuál es tu experiencia? ¿Alguna vez has probado TDD con cualquiera de estos tipos de desarrollo? ¿Conoces alguna herramienta o marco? ¿Puedes recomendar algún artículo o libro?

Answer 1

"¿Qué hay de desarrollo de GUI, redes, desarrollo de bases de datos, aplicaciones web?"

¿Por qué no funcionaría?

GUI. Lo único que TDD no puede hacer bien es evaluar el "aspecto" de la interfaz. Pero puede evaluar el comportamiento. Si hiciste bien tu diseño (separando modelo, vista y control), puedes probar el control y modelar fácilmente como TDD. ver, sin embargo, es más difícil escribir pruebas para. ("afirmar que el botón está debajo del campo" no es sensible.)

Redes. No estoy seguro que significa esto. Sin embargo, la definición de los servicios web RESTful funciona muy bien cuando se realiza a través de TDD. Defina los URI, escriba casos de prueba y luego cree los servicios que brindan las respuestas esperadas.

Aplicaciones web. El marco web de Django es compatible directamente con TDD para el desarrollo. Tienen pruebas unitarias para el modelo de datos web y las capas de control. Además, tienen pruebas unitarias para la presentación y el comportamiento de la página HTML.

Answer 2

Prueba groovy en los griales. Obtiene pruebas generadas automáticamente.

Cada vez que crea una clase de controlador automáticamente se genera una clase de prueba de unidad.

Del libro "La guía definitiva griales":

Griales separa las pruebas en las pruebas de “integración” “unidad” y. Las pruebas de integración inician el entorno completo , incluida la base de datos, y por lo tanto tienden a ejecutarse más lentamente. Además, las pruebas de integración están diseñadas típicamente para probar la interacción entre varias clases y , por lo tanto, requieren una aplicación más completa antes de poder ejecutarlas. Las pruebas unitarias, por otro lado, son pruebas de funcionamiento rápido, pero requieren que haga un uso extensivo de de simulaciones y talones. Los stubs son clases usadas en pruebas que imitan el comportamiento real de los métodos devolviendo valores arbitrarios codificados. En esencia, Mock hace lo mismo, pero exhibe un poco más de inteligencia al tener "expectativas". Por ejemplo, un simulacro puede especificar que "espera" que un método determinado sea invocado al menos una vez, o incluso diez veces si es necesario.

Answer 3

usted tiene algunos costos para hacer TDD:

• Al actualizar su código debe mantener su unidad de pruebas para comprobar si el nuevo comportamiento correcto.
  • vez que haya una gran cantidad de pruebas de unidad, cuando refactoriza, es necesario volver a escribir la unidad pone a prueba

me gusta TDD para un montón de cosas. Tenga en cuenta que el costo de mantenimiento anterior de mantener las pruebas de la unidad de trabajo podría significar que, aunque su código se ha vuelto más modular, la organización modular elegida es más difícil de cambiar. No puede reorganizar su código sin el costo adicional de volver a escribir todas las pruebas de su unidad. Ese es realmente el gran límite que he encontrado con TDD. Más tarde, cuando te das cuenta de que has cometido un error, ahora tienes todos estos gastos generales por los que tienes que pasar para refaccionar las cosas, mientras que antes estos cambios podían ocurrir de forma mucho más fluida. Entonces, para usar TDD, diría que necesitas tomar buenas decisiones cuando desarrolles el módulo por primera vez. No siempre es fácil en el mundo cambiante y ágil en el que vivimos;).

Ten en cuenta también:

• No todo puede ser puramente negro caja a prueba a través de un métodos de clases. Es decir, un método cuyo resultado depende de cuántos microsegundos han pasado desde la última vez que se llamó. Necesita agregar ganchos para controlar cuánto tiempo ha pasado y ver si obtiene la respuesta correcta.
• Las pruebas de unidades realmente no son apropiadas para todo. Ver si una GUI es utilizable por los humanos realmente nunca puede ser probada a través de unittest.

Answer 4

En cuanto a los límites de ir que es importante recordar que TDD es la estabilidad y la gestión del cambio - sin duda no ayuda particularmente a diseñar mejor sólo hace cumplir la ejecución de su diseño *. De hecho, crear una buena arquitectura de sistema requiere tanta reflexión como con cualquier otra metodología de desarrollo.

una variedad de límites existen, la mayoría de los cuales son ya que el software todavía requiere el ser humano:

• TDD no hace nada para ayudar a los intangibles como el diseño GUI y la experiencia general del usuario
• TDD no resuelve la basura de la basura en salida privado en su diseño
• TDD no resuelve los problemas ambientales (es decir, la creación de redes, I18N y dependientes del tiempo los errores tienden a deslizarse por las grietas)
• unidad de pruebas mismos necesitan de diseño (resuelto en mayor o menor medida dependiendo de marco)
• Las pruebas unitarias pueden aumentar la cantidad de trabajo requerido durante la refabricación (pero esperamos que esto se haya minimizado con su hermoso diseño).
• y el clásico: son únicos hardware> imposible unidad de prueba (la solución general es evitar embarazos únicos)

* A pesar de que he escrito eso, estoy seguro de cómo frase que correctamente.

Answer 5

Me pregunto qué marco/idioma que utiliza para su TDD si aún no se han dado en las partes más evidentes de donde es difícil:

• interfaces gráficas de usuario - Ciertos entornos y plataformas, en concreto, Los formularios web de Windows Forms y ASP.NET adolecen de inestabilidad práctica, porque no existe una manera fácil de aislar o burlarse de su comportamiento. Esta es una de las principales fuerzas impulsoras de ASP.NET MVC, para el caso.

• Persistencia - Cualquier tipo de persistencia, ya se trate de almacenamiento en disco, la conexión a una base de datos, a una red, o alguna otra forma de sistema externo sería una limitación, ya que todos ellos son pruebas de persistencia que dependen demasiado sobre el estado de un componente externo para tener éxito. Estas pruebas de integración se consideran pruebas frágiles. Burlarse se usa para mitigar el impacto de tales sistemas externos.

• Adopción - Incluso si están bien versados ​​en TDD, es una batalla cuesta arriba tratando de conseguir otros desarrolladores - y mucho menos toda tiendas de desarrollo - para usarlo. Muchos simplemente no ven el beneficio; son fácilmente desactivados por las curvas iniciales de aprendizaje y productividad abruptas. Encontrarás casos en los que eres el único que practica TDD en tu proyecto e incluso si lo aplicas, los otros desarrolladores presentarán pruebas de baja calidad y sin sentido. Esta razón no técnica es el mayor obstáculo para usar TDD en los sistemas de producción de la vida real que he enfrentado, y es una realización dolorosa cuando eres muy consciente de los beneficios.