Comenzando un nuevo proyecto con TDD

Estoy estudiando TDD y leí que también te ayuda a definir el diseño de la aplicación, ¿correcto?

Así que decidí comenzar a crear un nuevo proyecto para ayudarme a entenderlo mejor.

Quiero crear un sistema simple de registro de usuarios que solicite su nombre, dirección de correo electrónico, país (elegirá uno de una lista) y número de teléfono.

Entonces la pregunta es ...

¡Creé una nueva solución en VS 2010, agregué un nuevo proyecto de prueba y simplemente no sé qué pruebas escribir!

Como me ayudará a definir el diseño, ¿qué pruebas podría escribir aquí?

¡Gracias por cualquier ayuda!

Cuando escribe pruebas unitarias, está probando el comportamiento de su aplicación, por lo que la pregunta importante es qué hace su aplicación . Aquí hay un comienzo:

[TestFixture]
public class RegistrationTests
{
    [Test]
    public void Should_save_new_user_info()
    {
    }

    [Test]
    public void Should_throw_validation_exception_when_email_already_exists()
    {
    }

    [Test]
    public void Should_format_phone_number_when_country_code_is_us()
    {
    }
}

Simplemente crear un proyecto de prueba y escribir algunos métodos de prueba es una especie de TDD, pero en mi experiencia no es de mucha ayuda a menos que esté trabajando en una biblioteca donde hay una API conocida y las llamadas a métodos corresponden directamente a algo esperado por el usuario . Debe encontrar la lista correcta de pruebas, y para una aplicación no trivial, eso puede ser realmente difícil de hacer.

Recomiendo probar SpecFlow: sigue definiendo las pruebas muy bien separadas de la implementación y la estructura de los archivos de características lo obliga a pensar en lo que realmente está probando.

Cuando define una característica, simplemente escribe algo como

When a user is saved
Then the user should exist

Debido a que no está en un archivo de código en este momento, no está tentado a pensar en detalles de implementación como qué método se llama para crear un usuario o incluso en qué clase se implementa. Puede usar etiquetas para elegir diferentes implementaciones, así que a este nivel no importa si "el usuario está guardado" significa una llamada a CreateUser o abrir un navegador y enviar un formulario.

Una vez que haya definido las características, se generarán todas las pruebas y comenzarán a pasar a medida que implemente las definiciones de pasos y el código de aplicación real que se está probando.

Para una aplicación simple, solo puede crear los archivos de características, pero para cualquier cosa más compleja es útil reunir una especificación más completa de antemano. Para esto utilizo una aplicación de mapas mentales de iPad, pero puedes usar cualquier herramienta con la que te sientas más cómodo.

Comience con una lista de características de alto nivel como "Registro de usuario". Estos tienden a ser demasiado amplios para escribir pruebas directamente, por lo tanto, divídalos en subcaracterísticas que se puedan definir claramente y, por lo general, se asignen a una acción específica del usuario como "Guardar usuario" o "Ver usuario existente".

Cada una de estas subcaracterísticas necesitará una lista de escenarios que juntos definen por completo si la característica está funcionando o no, cosas como "Puede guardar un usuario válido" y "No puede guardar un usuario con nombre de usuario duplicado".

A medida que construya esta lista, generalmente quedará claro dónde debe ajustarse la estructura: si no puede encontrar ninguna prueba de escenario para una característica, o termina con demasiadas en una característica, entonces esa característica probablemente se define en el nivel equivocado y necesita ser dividido o cambiado.

Me pareció bueno hacer una copia de seguridad de mis primeros experimentos en TDD con algo de lectura y código de corte. El artículo de Wikipedia sobre el tema es muy bueno y le brindará una amplia variedad de otros recursos. Busque las cosas de Kent Beck en particular, una especie de padre de TDD.

Otra cosa que puede ayudarlo a ponerse en marcha es hacer katas, ejercicios de entrenamiento simples y casi sin sentido. Roy Osherove tiene algunos buenos.

Más allá de eso, solo tenga en cuenta las ideas clave de TDD: escriba una prueba a la vez y no continúe hasta que pasen todas las pruebas anteriores. Solo escriba suficiente código para satisfacer la prueba actual, evite la tentación de escribir más. A medida que avanza, deténgase de vez en cuando y piense si puede limpiar el código o las pruebas. Siempre desarrolle en rojo (prueba de falla), verde (prueba de aprobación), ciclo de refactorización.

Y para comenzar, tal vez comience con su requisito de nombre. ¿Qué vas a necesitar?

Probablemente necesitarás una clase. Escriba una prueba para eso (algunas personas se saltan esto pero al comenzar lo hacen para el ejercicio) y escriba la clase.

A continuación, su clase deberá almacenar un nombre. Escribe una prueba que demuestre que tu clase sí puede. Luego, nuevamente, escriba el código para pasar la prueba.

Entonces quizás tengas algunas reglas comerciales más. Tal vez quieras que tu nombre tenga una cantidad mínima de caracteres. Escriba la prueba, vea que falla, escriba el código.

Y así...

Creo que no es posible darle la idea de TDD en una respuesta corta. Necesitas "ver" sombody practicándolo, para sentirlo. El mejor recurso que he encontrado sobre ese tema es http://pragprog.com/titles/achbd/the-rspec-book . Antes de que me digas que Ruby no es tu idioma: ¡lee el prólogo del tío Bob! ;-)

Es posible que desee configurar una prueba que intente agregar varios valores diferentes en el campo de correo electrónico, algunos son válidos y otros no. No deje de desarrollar hasta que todas las pruebas den el valor esperado. Cosas como esas.

Como ha descrito el sistema, solo hay una prueba a nivel de aplicación:

[Prueba] public void Save_and_retrieve_user (String name, String email, ...) {// Guardar // Recuperar // Verificar}

A medida que refina los requisitos, agregue más pruebas.