Su jefe no apreciará TDD: pruebe este ejemplo de desarrollo basado en el comportamiento

Pruebas. A menudo se deja para el último minuto y luego se corta porque no tiene tiempo, tiene un presupuesto excesivo o cualquier otra cosa.

La gerencia se pregunta por qué los desarrolladores no pueden simplemente "hacerlo bien la primera vez", y los desarrolladores (especialmente en sistemas grandes) pueden quedar desprevenidos cuando diferentes partes interesadas describen diferentes partes del sistema, como la historia de los ciegos que describen un elefante.

Sin embargo, es inevitable que el primer paso en cada proyecto sea una discusión sobre los comportamientos del software o la función que se va a construir. Un cliente o empresario se acerca a alguien del equipo de desarrollo y le explica lo que quiere.

A veces, estas interacciones vienen en forma de una historia de usuario Agile. A veces vienen en forma de documentos de diseño, como en la entrada del blog de Chris Fox el año pasado. También podrían venir como diagramas de flujo o maquetas en Keynote, o incluso como llamadas telefónicas apresuradas.

Solo a partir de estas comunicaciones, un desarrollador es responsable de construir un sistema que “simplemente funcione”. Esto es especialmente difícil para los autónomos que trabajan fuera del sistema más grande.

¿Por qué se recortan las pruebas?

Hay una brecha obvia aquí: si el propietario de la empresa ha previsto los comportamientos del sistema desde el principio, ¿por qué probar que estos comportamientos realmente funcionan a menudo es el paso que se elimina?

La respuesta puede ser deslumbrantemente simple: las pruebas a menudo no se consideran capital compartido ; no se considera que tengan valor para el proyecto, porque “son solo para los ingenieros”, o de manera similar, que brindan valor a un solo departamento o grupo de personas.

¿Cómo ponemos a prueba este capital compartido, esta lista de comportamientos del sistema? Adoptando no solo el desarrollo basado en pruebas (TDD), sino también el desarrollo basado en el comportamiento (BDD).

¿Qué es BDD?

El desarrollo basado en el comportamiento debe centrarse en los comportamientos comerciales que implementa su código: el "por qué" detrás del código . Admite un flujo de trabajo centrado en el equipo (especialmente multifuncional).

He visto que Agile BDD funciona muy bien cuando un desarrollador y el propietario del producto Agile o un analista comercial se sientan juntos y escriben las especificaciones pendientes (para que el desarrollador las complete más tarde) en un editor de texto sin formato:

1. La persona de negocios especifica los comportamientos que quiere ver en el sistema.
2. El desarrollador hace preguntas basadas en su comprensión del sistema, al mismo tiempo que escribe comportamientos adicionales necesarios desde una perspectiva de desarrollo.

Idealmente, ambas partes pueden consultar la lista de comportamientos actuales del sistema para ver si esta nueva función interrumpirá las funciones existentes.

Descubrí que este simple acto me da suficientes restricciones para que pueda pensar como un desarrollador: "dado que tengo que implementar estas pruebas, ¿cómo me limita eso a mí o a todos a la especificación que puedo implementar en el código"? Dado que son especificaciones pendientes, son rápidos y fáciles de escribir en medio de la colaboración.

Este enfoque colaborativo me permite concentrarme en lo que la función proporciona al usuario final, y tener a la persona de negocios justo ahí me obliga a hablar sobre el comportamiento, no sobre la implementación. Esto resalta las diferencias en BDD vs TDD.

Veamos un ejemplo de Desarrollo Impulsado por el Comportamiento

El escenario: Eres un desarrollador en un equipo responsable del sistema de contabilidad de la empresa, implementado en Rails. Un día, un empresario te pide que implementes un sistema de recordatorios para recordar a los clientes sus facturas pendientes. Porque estás practicando BDD según este tutorial; (frente a TDD), te sientas con esa persona de negocios y comienzas a definir comportamientos.

Abre su editor de texto y comienza a crear especificaciones pendientes para los comportamientos que desea el usuario empresarial:

 it "adds a reminder date when an invoice is created" it "sends an email to the invoice's account's primary contact after the reminder date has passed" it "marks that the user has read the email in the invoice"

Este enfoque en el comportamiento durante el desarrollo hace que la prueba sea útil como verificación de que está creando la característica correcta, no solo que su código es correcto. Tenga en cuenta que la redacción está en lenguaje comercial, no en el lenguaje de implementación interna del sistema. No ve ni le importa que una factura belongs_to una cuenta, porque a nadie fuera del equipo de desarrollo le importa eso.

Algunos desarrolladores prefieren escribir casos de prueba en el acto, llamando a métodos en el sistema, configurando expectativas, así:

 it "adds a reminder date when an invoice is created" do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

El conjunto de pruebas fallará porque aún tenemos que escribir el código para establecer la reminder_date .

Vis-a-vis fallas en las especificaciones

Entiendo a los desarrolladores que escriben especificaciones defectuosas, pero con la persona de negocios a mi lado, esto nunca me ha funcionado. La persona de negocios equivocada se distraerá con los detalles o tomará este nuevo conocimiento e intentará microgestionar cosas sobre las que el desarrollador sabe más (diseño de base de datos adecuado, reutilización de código).

En mi experiencia, escribir más de una descripción general de una línea de un comportamiento específico aburrirá a la persona de negocios. Lo verán como un mal uso de su tiempo o se pondrán ansiosos por describir el próximo comportamiento mientras lo tienen en mente.

¿En qué se diferencia BDD de TDD?

Veamos esto de una manera diferente, con un enfoque de desarrollo basado en pruebas, y escribamos las pruebas pendientes:

 it "after_create an Invoice sets a reminder date to be creation + 20 business days" it "Account#primary_payment_contact returns the current payment contact or the client project manager" it "InvoiceChecker#mailer finds invoices that are overdue and sends the email"

Estas pruebas son útiles, pero solo para un grupo de personas: los ingenieros. BDD es útil para comunicarse con todos los miembros de un equipo de productos multifuncional.

Sin duda, puede realizar un desarrollo de prueba primero mientras tiene una mentalidad BDD mediante el uso de comportamientos pendientes. Primero, escribe la prueba; luego ejecutarlo (rojo); luego haz que funcione (verde); luego hazlo bien (refactorizar).

Se ha trabajado mucho en la comunidad de BDD para hacer que las verificaciones de afirmación dentro de la prueba se lean como en inglés. Aquí hay una prueba RSpec estereotipada:

 a = 42 a.should == 42

Este formato facilita la lectura posterior. Pero recuerde que esto no es lo que estamos haciendo aquí, el objetivo es reducir los comportamientos lo más rápido posible y hacer cumplir el principio de "un comportamiento probado por especificación". Idealmente, el título de la especificación pendiente debería indicarle lo que está probando.

BDD no se trata de formas sofisticadas de validar sus resultados; se trata de compartir los comportamientos esperados entre todos los miembros del equipo.

El desarrollo impulsado por el comportamiento tiene que ver con la colaboración y la comunicación

Volvamos a nuestro escenario: trabajando en el sistema contable de la empresa.

Usted recorre la funcionalidad del elemento con la persona de negocios, analizando el sistema a través de su interior (cómo encajan los objetos internamente) y analizando el sistema desde el exterior.

Piensa en algunas condiciones y le pregunta al analista de negocios qué sucede en los siguientes escenarios:

 * What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Y obtienes respuestas . Es importante que la persona de negocios entienda que usted no está tratando de perforar agujeros en su idea favorita, o ser demasiado pedante.

De esta manera, el Desarrollo Impulsado por el Comportamiento es una herramienta para ayudar a la colaboración e iniciar una conversación entre los dos departamentos. También es una forma de aclarar el alcance de una función deseada y obtener mejores estimaciones del equipo de desarrollo. Tal vez se dé cuenta de que no hay forma de calcular 10 días hábiles a partir de un momento determinado; esa es una característica adicional, separada, que deberá implementar.

Los desarrolladores tendrán consideraciones de desarrollador ("¿Qué quiere decir exactamente cuando dice 'día'?"), mientras que los empresarios tendrán sus propias consideraciones ("Por favor, no use el término atrasado aquí, eso significa algo diferente"). Hacer que un grupo u otro se dispare e intente escribir estas pruebas de comportamiento de lógica de negocios por sí mismos (la promesa de Cucumber) elimina la valiosa contribución de cada lado.

También es un buen sustituto cuando Agile Client ya no está físicamente en la sala: tener sus deseos en papel, mezclados con el análisis del desarrollador (y la traducción) de lo que está creando.

Documentos de diseño

Una publicación anterior del blog de Toptal, Chris Fox, habla sobre los documentos de diseño, especialmente al comienzo de un proyecto. Comprender y extraer los comportamientos comerciales se reduce de proyectos en los que el sistema es algo cognoscible, a aquellos que requieren décadas de programador-años para lograr y tienen cientos o miles de especificaciones de comportamiento.

El artículo de Chris también menciona el comportamiento de los elementos en pantalla, y esta es un área en la que estoy constantemente en desacuerdo con los diseñadores: "¿Cómo se ve este botón cuando está atenuado?" o "¿Cómo se ve esto en las pantallas de 11", porque ¿Esta página obviamente está diseñada para pantallas de 24”? Esta ida y vuelta con la persona de negocios puede encontrar lagunas en los recursos gráficos de un proyecto o el diseño de una página.

En equipos multidisciplinarios muy grandes, hay muchos miembros del equipo con sus propias preocupaciones: diseñadores, desarrolladores, posiblemente alguien de operaciones, el administrador de la base de datos, tal vez gente de control de calidad (sí, ¡hay un lugar para todos en TDD y BDD!), cada con sus propias preocupaciones y preguntas. BDD puede impulsar esta colaboración más que el desarrollo basado en pruebas. De "¿qué sucede cuando los datos son demasiado grandes para esta tabla?" a, "Hmmm, esa será una consulta costosa, querremos almacenar eso en caché de alguna manera" a, "Espera, ¿debería el usuario ver toda esa información confidencial?", puede haber más en juego que solo un desarrollador y un analista de negocios con preguntas sobre esta nueva función

El desarrollo impulsado por el comportamiento se trata de artefactos compartidos

¿Qué es un artefacto compartido?

Me gusta pensar en los "artefactos" en la ingeniería de software como cosas potencialmente físicas que describen el proyecto o el equipo del proyecto, y que se pueden encontrar seis meses después. Los buenos artefactos explican por qué las cosas son como son.

Las conversaciones de pasillo no son artefactos. Los dibujos en pizarra tampoco. Dibujos de pizarra que se convierten en grandes documentaciones de clase larga o documentos de diseño: estos son artefactos. Las actas de las reuniones también son artefactos.

Un artefacto es un código fuente guardado en un repositorio o espacio compartido, y tickets en el sistema de tickets, o notas en el Wiki interno, o incluso registros de chat persistentes.

Los artefactos compartidos son, en mi opinión, los mejores artefactos . Muestran no solo por qué algo es como es, sino también por qué existe en la aplicación.

¿Cómo los usas en BDD?

Los comportamientos deben ser un artefacto compartido del equipo: ¡las pruebas no deben ser solo un trabajo ocupado para los programadores! Si bien es mejor tener un sistema en el que todo el equipo pueda ver fácilmente las especificaciones actuales (quizás el sistema de implementación también extrae y guarda la lista de comportamientos en un área privada del sitio o un wiki), también puede hacerlo manualmente cada pique.

El nombre del juego es "ayudar a los desarrolladores a crear las especificaciones que necesitamos para ofrecer valor comercial más rápido, colaborar entre departamentos y hacer mejores estimaciones".

Esta comprensión de toda la empresa de lo que hace el sistema es también una forma de capital. Es el “por qué” del “cómo” del código.

Conclusión

¿Cómo resolvemos el problema del software con errores que se entrega a los clientes? Al asegurarse de que las pruebas no se vean como algo que "solo les importa a los desarrolladores".

Describir y comprender las necesidades de un sistema tiene muchos beneficios más allá de la corrección del código: establecer un diálogo interdepartamental y asegurarse de que se satisfagan todas las preocupaciones de las partes interesadas (y no solo las partes interesadas con títulos grandes y elegantes). Usar el desarrollo basado en el comportamiento para comprender estas necesidades desde el principio y probar los comportamientos comerciales externos que preocupan a todo el equipo, es una excelente manera de garantizar un proyecto de calidad.