BDD: Comenzando

Estoy empezando con BDD y esta es mi historia:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

Tengo algunas dudas ...

¿Debo escribir mis escenarios antes de codificar algo o primero debo escribir un escenario y luego escribir código, escribir un escenario nuevamente y luego escribir código, y así sucesivamente ...?

Si debo escribir mis escenarios antes, ¿pueden aprobarse mis pasos y el código de producción aún no se realiza?

¿Cuándo debo refactorizar mi código? ¿Después de que se realiza la función o después de la implementación de cada escenario?

De la historia, infiero que estás codificando por tu cuenta.

Normalmente, el propósito de BDD es permitir conversaciones, particularmente entre la empresa y los desarrolladores, para que el equipo pueda estar seguro de que han alcanzado un entendimiento común. También nos gusta incluir probadores, porque pueden detectar cuando hemos perdido escenarios.

Si está haciendo esto por su cuenta, tome un pato de goma y explique el comportamiento de su aplicación al pato. Da algunos ejemplos de cómo debería funcionar. Esos serán tus escenarios.

Para empezar, sugeriría no automatizar esos escenarios. Puede escribirlos si lo desea. Recuerde que los resultados comerciales que compartió con el pato tienen el nivel adecuado para expresarlos. Ahora debe tener una idea de cómo se comporta la aplicación y puede ejecutar los escenarios manualmente. Me gusta tratar todo lo que aún no funciona como un error . A veces he comenzado con la automatización, pero solo cuando sé muy bien cómo funciona el sistema, estoy familiarizado con las herramientas y la interfaz de usuario se entiende bien. Incluso entonces, a menudo tengo que modificarlo un poco cuando escribí el código.

En un nivel inferior, dígale a su pato cómo se comportará cada clase. Proporcione algunos ejemplos. Los patos de goma son perfectamente capaces de comprender el lenguaje técnico. Ahora tiene su BDD de nivel de unidad, también conocido como pruebas de unidad. El ciclo rojo-verde-refactor ocurre aquí. (No tiendo a necesitar refactorizar mucho más, porque estoy pensando en las responsabilidades de mis clases, redactando en un lenguaje orientado a los negocios, y de todos modos tiende a caer de una manera bastante hermosa. Pero He estado haciendo esto por un tiempo ahora. Está bien si lo haces).

No lo refactorices demasiado. Todavía queremos recibir comentarios sobre nuestro código, porque siempre hay cosas que no sabemos que no sabemos . La perfección es tu enemigo aquí. Hazlo lo suficientemente bueno, hazlo legible, luego sigue adelante. Si necesita hacer algo perfecto para realizar más cambios, hágalo cuando realice más cambios.

Si tiene la oportunidad de recibir comentarios sobre sus escenarios de las partes interesadas del negocio, pero no están con usted, puede enviarles escenarios tan pronto como los haya escrito y antes de automatizarlos. Es posible que también desee enviar una maqueta de la interfaz de usuario para que puedan correlacionar palabras con acciones. No te adelantes demasiado a la codificación con esto. Trabaje con la suposición de que lo que ya ha hecho está mal y necesita recibir comentarios para saber cómo.

Como pista final, generalmente no exprese historias desde el punto de vista del usuario (escenarios, sí, pero no historias). No son historias de usuarios. Probablemente debería leer algo como:

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

Hay alguna meta de nivel superior que estás buscando, de todos modos. Esto también lo ayudará a extraer las capacidades que necesita. Buena suerte y disculpas por la publicación extra larga.

¿Debo escribir mis escenarios antes de codificar algo o primero debo escribir un escenario y luego escribir código, escribir un escenario nuevamente y luego escribir código, y así sucesivamente ...?

Ambos funcionarán. Elegir uno.

No importa mucho

Cuantos más escenarios tenga, más diseño podrá hacer por adelantado.

Cuantos más escenarios tenga, más tiempo llevará hacer algo.

¿Cuándo debo refactorizar mi código? ¿Después de que se realiza la función o después de la implementación de cada escenario?

No. Refactoriza cuando se hace difícil diseñar el siguiente escenario.

Usa verbos descriptivos

Feature: CONVERT Months and days to days

No tome decisiones de diseño en historias ["Necesito una página web" es una decisión de diseño]

As a date conversion fan
I want to convert days and months into days

Use objetivos de valor comercial en las historias

So that [some business reason]

Escriba tantas características e historias como pueda antes de comenzar a codificar; las historias se informan entre sí , influyen en las características e informan el diseño.

Refactorizar después de cada historia. Refactor rojo-verde.