TDD con requisitos poco claros

Question

Sé que TDD ayuda mucho y me gusta este método de desarrollo la primera vez que crea una prueba y luego implementa la funcionalidad. Es muy claro y correcto.

Pero debido a cierto sabor de mis proyectos, a menudo sucede que cuando comienzo a desarrollar algún módulo, sé muy poco acerca de lo que quiero y cómo se verá al final. Los requisitos aparecen a medida que desarrollo, puede haber 2 o 3 iteraciones cuando borro todo o parte del código anterior y escribo nuevo.

veo dos problemas: 1. quiero ver el resultado tan pronto como sea posible entender son mis ideas bien o mal. Las pruebas unitarias ralentizan este proceso. Por lo tanto, a menudo sucede que escribo pruebas unitarias después de que el código finaliza, lo que se sabe que es un mal patrón. 2. Si primero escribo las pruebas, necesito reescribir el código no solo dos o más veces sino también las pruebas. Lleva mucho tiempo.

¿Podría alguien decirme cómo se puede aplicar TDD en tal situación?

¡Gracias de antemano!

Answer 1

Quiero ver el resultado lo antes posible para comprender si mis ideas son correctas o incorrectas. Las pruebas unitarias ralentizan este proceso.

I disagree. Las pruebas unitarias y TDD a menudo pueden acelerar la obtención de resultados porque te obligan a concentrarte en los resultados en lugar de implementar toneladas de código que quizás nunca necesites. También le permite ejecutar las diferentes partes de su código a medida que las escribe para que pueda ver constantemente los resultados que obtiene, en lugar de tener que esperar hasta que se termine todo el programa.

Answer 2

TDD le ayuda a expresar la intención de su código. Esto significa que al escribir la prueba, debe decir lo que espera de su código. Cómo se cumplen sus expectativas es entonces secundario (esta es la implementación). Hágase la pregunta: "¿Qué es más importante, la implementación o cuál es la funcionalidad provista?" Si es la implementación, entonces no tiene que escribir las pruebas. Si es la funcionalidad provista, primero escribir las pruebas te ayudará con esto.

Otra cosa valiosa es que, mediante TDD, no implementará una funcionalidad que no será necesaria. Usted solo escribe el código que necesita para satisfacer la intención. Esto también se llama YAGNI (No vas a necesitarlo).

Answer 3

Me parece que TDD funciona particularmente bien en este tipo de situación; de hecho, diría que tener requisitos poco claros y/o cambiantes es realmente muy común.

Encuentro que los mejores usos de TDD es asegurar que su código esté haciendo lo que espera que haga. Cuando escribe cualquier código, debe saber lo que quiere que haga, independientemente de si los requisitos son claros o no. La fortaleza de TDD aquí es que si hay un cambio en los requisitos, puede simplemente cambiar una o más de las pruebas de su unidad para reflejar los requisitos modificados, y luego actualizar su código mientras está seguro de que no está rompiendo otro (sin cambios)) funcionalidad.

Creo que una cosa que hace tropezar a muchas personas con TDD es la suposición de que todas las pruebas deben escribirse antes de tiempo. Creo que es más efectivo usar la regla general de que nunca se escribe ningún código de implementación mientras se pasan todas las pruebas; esto simplemente asegura que todo el código esté cubierto, al tiempo que garantiza que está comprobando que todo el código hace lo que quiere que haga sin preocuparse de escribir todas sus pruebas por adelantado.

Answer 4

En esta primera fase de prototipo me parece suficiente para escribir código comprobable. Es decir, cuando escribe su código, piense en cómo hacer posible la prueba, pero por ahora, concéntrese en el código en sí y no en las pruebas.

Sin embargo, debe tener las pruebas en su lugar cuando cometa algo.

Answer 5

Aquí hay una publicación de blog que me pareció poderosa para explicar el uso de TDD en una escala de proceso de diseño muy iterativa: http://blog.extracheese.org/2009/11/how_i_started_tdd.html.

Answer 6

El uso de TDD en realidad podría hacer que escriba el código más rápido; no poder escribir una prueba para un escenario específico podría significar que hay un problema en los requisitos.
Cuando usa TDD, debe encontrar estos lugares problemáticos más rápido en lugar de escribir el 80% de su código.

Hay algunas cosas que puede hacer para hacer sus pruebas más resistentes al cambio:

1. Usted debe tratar de reutilizar código dentro sus pruebas en una forma de fábrica métodos que crea su prueba objetos junto con los métodos de verificación que verifican el resultado de la prueba. Esta forma si algún cambio importante en el comportamiento ocurre en su código tiene menos código para cambiar en su prueba.

2. Uso IoC contenedores en lugar de pasar argumentos a sus principales clases - de nuevo si la firma del método cambios que no es necesario cambiar todas sus pruebas.

3. Realice pruebas unitarias cortas y aisladas: cada prueba debe verificar solo un aspecto de su código y utilizar el marco de simulación/aislamiento para hacer que la prueba sea independiente de objetos externos.

4. Pruebe y escriba el código solo para la característica requerida (YAGNI). Intenta preguntarte qué valor recibirá mi cliente del código que estoy escribiendo. No cree una arquitectura sobrecomplicada sino que cree la funcionalidad necesaria pieza por pieza mientras refactoriza su código sobre la marcha.

Answer 7

No hay manera de escapar de - si usted está midiendo el tiempo que tarda en código sólo por el tiempo que se tarda en escribir clases, etc, a continuación, que va a tomar más tiempo con TDD. Si tienes experiencia, agregará un 15%; si eres nuevo, te llevará al menos un 60% más de tiempo, si no más.

PERO, en general, será más rápido. ¿Por qué?

• escribiendo una primera prueba de que está especificando lo que quiere y entregando solo eso y nada más - por lo tanto, el ahorro de tiempo escribiendo código no utilizado
• sin pruebas, se podría pensar que los resultados son tan obvio que lo que He hecho es correcto, cuando no lo es. Las pruebas demuestran que lo que has hecho es correcto.
• obtendrá retroalimentación más rápida de pruebas automatizadas que haciendo pruebas manuales
• con la prueba manual, el tiempo necesario para probar todo lo que su aplicación crece aumenta rápidamente - lo que significa que deje de hacerlo
• con pruebas manuales Es fácil de cometer errores y "ver" algo que pasa cuando no es así, esto es especialmente cierto si los está ejecutando una y otra y otra vez
• (buenas) pruebas de unidad le dan un segundo cliente a su código que a menudo destaca problemas de diseño que podría perderse de lo contrario

Agregue todo esto y mida desde el inicio hasta la entrega y TDD es mucho, mucho más rápido: obtiene menos defectos, corre menos riesgos, progresa a un ritmo constante (lo que facilita la estimación) y la lista continúa .

TDD te hará más rápido, sin dudas, pero no es fácil y deberías permitirte algo de espacio para aprender y no desanimarte si inicialmente parece más lento.

Finalmente, debe consultar algunas técnicas de BDD para mejorar lo que está haciendo con TDD. Comience con la función que desea implementar e ingrese al código desde allí sacando historias y luego escenarios. Concéntrese en implementar su escenario de solución por escenario en secciones verticales delgadas. Hacer esto ayudará a aclarar los requisitos.

Answer 8

En mi humilde opinión, su principal problema es cuando tiene que eliminar algún código. Esto es waste y esto es lo que se debe abordar primero.

Quizás podría prototipar, o utilizar "soluciones puntuales" para validar los requisitos y sus ideas, y luego aplicar TDD en el código real, una vez que los requisitos sean estables.

El riesgo es aplicar esto y tener que enviar el prototipo.

También podría probar el "camino soleado" primero y solo implementar el resto, como el manejo de errores ... después de que se hayan establecido los requisitos. Sin embargo, la segunda fase de la implementación será menos motivante.

¿Qué proceso de desarrollo está utilizando? Suena ágil ya que estás teniendo iteraciones, pero no en un entorno que lo soporte por completo.

Answer 9

Joshua Block comentó algo similar en el libro "Codificadores en el trabajo". Su consejo fue escribir ejemplos de cómo se usaría la API (aproximadamente una página de longitud). Luego, piense mucho en los ejemplos y la API y refactorice la API. Luego escribe la especificación y las pruebas de la unidad. Sin embargo, prepárese para refactorizar la API y reescribir la especificación a medida que implementa la API.

Answer 10

TDD, para casi cualquier persona, ralentizará el desarrollo inicial. Por lo tanto, si la velocidad de desarrollo inicial es 10 en una escala de 1-10, con TDD puede obtener alrededor de un 8 si es competente.

Es el desarrollo después de ese punto que se pone interesante. A medida que los proyectos crecen, la eficiencia del desarrollo generalmente disminuye, a menudo a 3 en la misma escala. Con TDD, es muy posible seguir estando en el rango 7-8.

Busque "deuda técnica" para una buena lectura. En lo que a mí respecta, cualquier código sin pruebas unitarias es efectivamente deuda técnica.

Answer 11

Cuando trato con requisitos poco claros, sé que mi código tendrá que cambiar. Tener pruebas sólidas me ayuda a sentirme más cómodo al cambiar mi código. Practicar TDD me ayuda a escribir pruebas sólidas, y es por eso que lo hago.

Aunque TDD es principalmente una técnica de diseño, tiene un gran beneficio en su situación: alienta al programador a considerar detalles y escenarios concretos. Cuando hago esto, noto que encuentro brechas o malentendidos o falta de claridad en los requisitos con bastante rapidez. El acto de intentar escribir pruebas me obliga a lidiar con la falta de claridad en los requisitos, en lugar de intentar barrer esas dificultades bajo la alfombra.

Así que cuando tengo requisitos poco claros, practico TDD porque me ayuda a identificar los problemas de requisitos específicos que necesito abordar, pero también porque me alienta a escribir código que me resulta más fácil de modificar ya que entiendo más sobre lo que necesito construir