¿Cómo mejora Behavior Driven Development la claridad cuando los lenguajes naturales son ambiguos?

Actualmente estoy explorando marcos de prueba BDD como pepino y me resulta curioso cuando la gente dice

Como los archivos de características están en un lenguaje natural simple, mejora la claridad y brinda una visión clara

pero, ¿no es el lenguaje natural la causa de la mayoría de los problemas que tenemos en Ingeniería de software?

El lenguaje natural es ambiguo y esa es la razón por la que muchos proyectos de software fallan debido a la mala interpretación de los requisitos de los clientes y la comprensión del desarrollador. No entiendo el nicho aquí.

Sí, dividir las pruebas en pequeñas acciones factibles tiene sentido y proporciona un cierto nivel de claridad, pero ¿eso mejora la productividad en general?

PD: No soy un experto y no estoy haciendo una opinión aquí. Tengo curiosidad por entender el concepto.

Estás en lo correcto. BDD no elimina los problemas con la ambigüedad del lenguaje, en absoluto. Como otros señalaron, los fragmentos que se traducen deben coincidir definiéndolos adecuadamente, pero esto tampoco resuelve el problema de ambigüedad subyacente.

Ahora, ¿por qué vale la pena BDD a pesar de no resolver este problema? Hay algunas razones y esta lista ciertamente no está completa.

La ambigüedad no ha sido resuelta

Esta no es una razón a favor de BDD ni en contra de ella. Pero cuando lo contrasta con otros enfoques, como historias de usuarios o requisitos, todos los enfoques de desarrollo de SW sufren de ambigüedad en el lenguaje, ya que todos comienzan de una forma u otra con una formulación de lenguaje natural.

Técnicamente, el problema de la ambigüedad del lenguaje se ha resuelto con lenguajes artificiales como el lojban , pero, de nuevo, es muy probable que su cliente y los desarrolladores no conozcan ese idioma.

Lengua ubicua

BDD va de la mano con la idea de un lenguaje ubicuo. Ser capaz de especificar escenarios junto con todos los clientes, evaluadores y desarrolladores, solo le da a BDD una ventaja sobre otros enfoques.

Considere un ingeniero de requisitos tradicional escribiendo todos los requisitos. Una vez que, como probador o cliente, obtenga ese documento de 300 páginas lleno de requisitos para revisar, tendrá muchos más problemas apremiantes que la terminología que se utilizó allí.

Las historias de usuarios mejoran un poco en ese frente, ya que también incluyen a todos los interesados ​​en su creación. En términos del lenguaje ubicuo, no diría que BDD o las historias de los usuarios son mejores, aunque difieren significativamente en el siguiente punto.

Testabilidad

Un aspecto importante de BDD es que sus especificaciones son realmente ejecutables (a través de Cucumber o similares). Ni los requisitos ni las historias de los usuarios ofrecen esta característica. Para mí personalmente, ese es el principal punto de venta para BDD.

Compare eso con los requisitos tradicionales: hemos estado diciendo a los ingenieros de requisitos durante años que sus requisitos deben ser comprobables. Sin embargo, cada proyecto ve un caso en el que los evaluadores se dan cuenta de que no tienen idea de cómo probar un determinado requisito.

Las historias de los usuarios, si se hacen correctamente, incluyen evaluadores en su etapa inicial de creación para asegurarse de eso. Desafortunadamente, este es un caso de teoría que choca con el mundo real, donde he visto numerosas historias que ningún probador ha visto antes.

BDD, por otro lado, le proporciona automáticamente un escenario de prueba ejecutable. No hay excusas ni formas de evitarlo (bueno, a menos que ignore por completo las capas de automatización y simplemente escriba los escenarios para la poesía elegante).

En términos más generales, Test First es un principio que ha sido muy gratificante en todas las etapas del desarrollo de software y BDD es su aplicación en la capa más externa del desarrollo (en comparación con TDF, por ejemplo, en el nivel de la unidad).

Resumen

En resumen, BDD no lo libera de los problemas de la ambigüedad del lenguaje natural. Sin embargo, lo ayuda a abordar ese problema a través de dos puntos importantes: centrarse en un lenguaje ubicuo para reducir las ambigüedades (¡no las eliminará por completo, pero ayuda mucho!) Y al obligarlo a escribir ejecutable especificaciones. El último punto está ayudando a abordar los problemas de ambigüedad principalmente porque ese es el punto donde las ambigüedades comienzan a aparecer como problemas de otra manera.

Cuando algo está escrito en "lenguaje natural", esto puede significar varias cosas:

• Esto es literalmente inglés. Como el inglés es un idioma muy ambiguo e impreciso, este modo de entrada no es satisfactorio en el contexto del desarrollo de software.

• Esto es inglés, pero los términos relevantes están definidos con precisión. Dicho lenguaje se usa en documentos legales o textos matemáticos.

• Este es un lenguaje formal, pero el lenguaje se modela muy de cerca de las convenciones del lenguaje natural. Esto describe todos los lenguajes de programación, hasta cierto punto. Cuanto más parecido al inglés es el idioma formal, más fácil es comprenderlo para los lectores no capacitados. Ejemplos notables de lenguajes de programación con este objetivo incluyen COBOL y SQL: select id, name from persons where age > 18es inmediatamente obvio. La desventaja de estos idiomas es que necesita comprender el lenguaje formal para escribir código de trabajo. Además, estos idiomas suelen ser muy detallados.

DDD sugiere que el proyecto use un lenguaje omnipresente para describir el dominio. Este es esencialmente el caso 2: defina términos relevantes para que pueda comunicarse con precisión dentro del lenguaje natural.

El pepino en sí es el caso 3: un lenguaje formal que tiene la intención de leer muy cerca del inglés normal. Más precisamente: Cucumber es un marco que le permite definir un lenguaje formal simple que se puede utilizar para expresar requisitos / pruebas. El punto aquí es que el mismo documento representa los requisitos de lenguaje natural y las pruebas ejecutables automáticamente, por lo que los dos siempre estarán sincronizados. Puede leer un escenario de pepino y verificar que expresa sus requisitos correctamente sin tener que entender cómo funciona todo esto.

Pepino funciona haciendo coincidir el documento con fragmentos conocidos de lenguaje natural. Estos fragmentos deben definirse primero. Para escribir un escenario en Cucumber, debe conocer los fragmentos disponibles: el software no le leerá la mente. Estos fragmentos también son una fuente de posibles problemas: cuando implementa el comportamiento de un fragmento de texto, su código puede hacer algo ligeramente diferente de lo que sugiere el texto del fragmento. Es poco probable que esto sea un problema si se usa el mismo fragmento muchas veces. Por lo tanto, Pepino es muy adecuado para describir reglas comerciales que consisten en un conjunto más pequeño de condiciones, acciones y resultados. Otros marcos de prueba podrían ser mejores si cada fragmento se usara solo una o dos veces, por ejemplo, porque la configuración para cada caso de prueba es única.

@ Raghuram8892, el texto después de las palabras clave Given / When / Then / And debe coincidir con el "fragmento"; de lo contrario, el paso fallará como indefinido o "pendiente". Como tal, cae directamente en el caso 3.

Con respecto al "inglés", el pepino y su idioma, el pepinillo está diseñado para uso internacional. Puede invocar el comando, cucumber --i18n helppara ver la lista de idiomas admitidos actualmente y cucumber --i18n $CODEpara ver las palabras clave de un código de idioma en particular. Por ejemplo, cucumber --i18n eoda las palabras clave para esperanto.