TDD: ¿Qué sucede antes de la primera prueba unitaria?

Principalmente entiendo la teoría de TDD, pero no puedo entender cómo comenzar. Me siento a escribir una prueba unitaria para un proyecto personal y me doy cuenta. . . No tengo idea de lo que estoy probando. Qué objetos, qué funcionalidad, etc.

Por ejemplo, digamos que quiero escribir una aplicación para ayudar a nuestra familia a administrar las tareas. Aquí hay algunas preguntas en mi mente: ¿Cómo paso de esta idea a mi primer examen? ¿Cuánto se debe decidir antes de comenzar y cuánto debo calcular después de comenzar a escribir exámenes? ¿Cuándo tomo decisiones como si almacenar datos en un archivo de texto o una base de datos? ¿Debería realizarme pruebas de aceptación del usuario antes de comenzar? ¿Debo tener la interfaz de usuario diseñada? ¿Debo tener una especificación? (Me doy cuenta de que al menos algunas de estas preguntas de ejemplo están probablemente en un "área gris").

Además de la pregunta del título sobre cómo llegar a la primera prueba unitaria, ¿podría dar un ejemplo de cómo podría ser la primera prueba unitaria para un proyecto como el proyecto de muestra?

Me gusta comenzar con una lista de características, y para cada característica escribir las historias de los usuarios, luego, para cada historia, escribir descripciones de prueba.

Piense en el diseño por un momento, luego elija una descripción de prueba y comience a codificar: red-green-refactor.

Repita hasta que pasen todas las pruebas.

Sí, las pruebas de aceptación deben considerarse como parte de esto, adjuntas a la historia apropiada.

Has descubierto cómo TDD se trata de diseño desde el principio. Antes de escribir su primera prueba, debe pensar en cuál será su primer bit de funcionalidad y cómo se vería su programa si esa funcionalidad estuviera funcionando.

Los desarrolladores que no usan TDD también tienen que pensar en eso, pero pueden "simplemente sumergirse" y comenzar a escribir algo, cualquier cosa. Pero "algo, cualquier cosa" no siempre está en el camino hacia la entrega del programa que creía que se proponía escribir. ¿Que es? Bueno, ¿cómo sería tu programa si estuviera funcionando? ¿Qué pruebas pasaría?

Quiero escribir una aplicación para ayudar a nuestra familia a administrar las tareas.

Frio. Si esa aplicación funcionara, ¿qué haría? Bueno, una tarea probablemente podría asignarse a una persona, ¿verdad?

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

Hay un comienzo No es el lugar donde debe comenzar, no necesariamente el mejor lugar para comenzar, pero es un lugar. Es algo que desea que su código admita (aunque estoy seguro de que puede encontrar mejores nombres). Comienza allí, mira cómo falla. Hazlo pasar. Limpialo. Enjabonar, enjuagar, repetir.

Sí, TDD tiene este problema. Es por eso que ahora recomiendo Behavior Driven Development.

Comience manualmente. Escriba algo similar a una historia de usuario:

• Como usuario
• Cuando selecciono Agregar al carrito de compras, quiero que el producto se agregue de forma transparente
• Para que pueda continuar mi experiencia de compra sin interrupciones

¿Cuáles son las características que respaldan ese objetivo (la parte 'Así que')?

• Cuando se agrega un artículo al carrito de compras
  • El carrito de compras del usuario contendrá el nuevo artículo.
  • El total de artículos en el carrito aumentará en uno
  • El usuario no debe ser redirigido
  • Una opción de retirar ahora estará disponible
• Cuando hay dos artículos en el carrito de compras y el usuario decide pagar
  • El usuario será redirigido a la página de pago
  • Ambos elementos serán visibles

Estas son todas las cosas que puede y debe verificar manualmente.

Haz esto por un rato. Luego, como un buen desarrollador, comience a buscar formas de automatizar piezas redundantes. Esto variará dependiendo de cuál sea su plataforma, pero la mayoría tiene marcos decentes disponibles.

.Net tiene WatiN para automatizar la página web o, si desea probar una API, recomendaría la adición de Subspec a xUnit o MSpec (también puede hacerlo con cualquier marco de prueba, solo eso hace que sea más fácil nombrar sus pruebas de una manera que apoya este estilo de pensamiento).

Ruby tiene pepino para las pruebas de automatización y rspec para las pruebas de API de nivel inferior

Javascript tiene jazmín y qUnit.

punto punto punto

¿Cómo paso de esta idea a mi primera prueba? ¿Cuánto se debe decidir antes de comenzar y cuánto debo calcular después de comenzar a escribir exámenes?

Divide tu aplicación en historias pequeñas. ("Como usuario, quiero hacer doble clic en un icono e iniciar el programa". O "Como usuario, quiero abrir mi navegador e ir al programa". Lo que sea).

Luego desglosa la historia en algunas tareas. (por ejemplo, cree un proyecto en Eclipse, configure un repositorio de código) Cuando llegue a una tarea de codificación, escriba su primera prueba.

¿Cuándo tomo decisiones como si almacenar datos en un archivo de texto o una base de datos?

Si no estás seguro, elige el que parezca más simple y hazlo. (probablemente el archivo de texto) Si te das cuenta de que has cometido un error, refactoriza. Si sus pruebas están bien estructuradas, debería poder hacer que el back-end cambie y detectar los efectos secundarios no deseados que surgen.

Me sorprende que ninguna de las respuestas contenga una mención de lo que haces antes de escribir tu primera prueba, que es crear una lista de pruebas . Las fases de redacción y diseño de historias mencionadas en otras respuestas informan una lista de pruebas y es el precursor directo de escribir una prueba que parece estar buscando.

Para obtener más información sobre TDD, recomendaría Test Driven Development By Example de Kent Beck. También tiene un screencast de TDD que sigue el desarrollo de una biblioteca no trivial en un estilo TDD puro con explicaciones de Kent en cada paso del proceso. Creo que es un gran ejemplo de TDD en la práctica, incluso si se hace (por necesidad) en un entorno artificial.

Antes de la primera prueba unitaria, piensa en lo que quiere que suceda y luego piensa cómo probaría eso. Luego escriba esa prueba, vea cómo falla e implemente un código para que pase.

Enjuague, repita, etc.

Para mí, lo importante es pensar en cómo probarlo, y es lo que puede impulsar su diseño.