Como o Behavior Driven Development melhora a clareza quando as linguagens naturais são ambíguas?

Atualmente, estou explorando estruturas de teste BDD como pepino e acho curioso quando as pessoas dizem

como os arquivos de recursos estão em linguagem natural simples, melhora a clareza e oferece uma visão clara

mas, a linguagem natural não é a causa da maioria dos problemas que temos na engenharia de software?

A linguagem natural é ambígua e é por isso que muitos projetos de software falham devido à interpretação incorreta dos requisitos dos clientes e à compreensão do desenvolvedor. Eu não entendo o nicho aqui.

Sim, dividir os testes em pequenas ações factíveis simples faz sentido e fornece um certo nível de clareza, mas isso melhora a produtividade como um todo?

PS: Não sou especialista e não estou opinando aqui. Estou apenas curioso para entender o conceito.

Você está certo. O BDD não elimina problemas com a ambiguidade da linguagem - nem um pouco. Como outros apontaram, os trechos traduzidos precisam ser correspondidos definindo-os adequadamente, mas isso também não trata do problema de ambiguidade subjacente.

Agora, por que o BDD realmente vale a pena, apesar de não resolver esse problema? Existem alguns motivos e esta lista certamente não está completa.

A ambiguidade não foi resolvida

Esta não é uma razão a favor do BDD nem contra ela. Mas quando você o compara a outras abordagens, como histórias de usuário ou requisitos, todas as abordagens de desenvolvimento de SW sofrem de ambiguidade de linguagem, pois todas começam de uma maneira ou de outra com uma formulação de linguagem natural.

Tecnicamente, o problema da ambiguidade de linguagem foi resolvido com linguagens artificiais como o lojban , mas, novamente, é provável que seu cliente e desenvolvedores não conheçam essa linguagem.

Linguagem onipresente

O BDD anda de mãos dadas com a idéia de uma linguagem onipresente. Ser capaz de especificar cenários em conjunto com todos os clientes, testadores e desenvolvedores, apenas dá ao BDD uma vantagem sobre outras abordagens.

Considere um engenheiro de requisitos tradicional anotando todos os requisitos. Depois que você, como testador ou cliente, obtiver o documento de 300 páginas cheio de requisitos para revisão, você terá muito mais problemas prementes do que a terminologia usada lá.

As histórias de usuários se saem um pouco melhor nessa área, pois também incluem todas as partes interessadas em sua criação. Em termos de linguagem onipresente, eu não diria que o BDD ou as histórias de usuários são melhores - embora elas diferam significativamente no próximo ponto.

Testabilidade

Um aspecto importante do BDD é que suas especificações são realmente executáveis ​​(via pepino ou similar). Nem os requisitos nem as histórias do usuário oferecem esse recurso. Para mim, pessoalmente, esse é o principal ponto de venda do BDD.

Compare isso com os requisitos tradicionais - informamos há muito tempo aos engenheiros de requisitos que seus requisitos devem ser testáveis. No entanto, todo projeto vê um caso em que, em algum ponto da linha, os testadores percebem que não têm idéia de como testar um determinado requisito.

As histórias de usuários, se bem feitas, incluem testadores em seu estágio inicial de criação para garantir isso. Infelizmente, este é um caso de teoria em conflito com o mundo real, onde eu já vi inúmeras histórias que nenhum testador viu antes.

O BDD, por outro lado, automaticamente fornece um cenário de teste executável. Não há desculpas nem maneiras de contornar isso (a menos que você ignore completamente as camadas de automação e apenas anote os cenários para a poesia sofisticada).

De maneira mais geral, o Test First é um princípio que tem sido muito gratificante em todos os estágios do desenvolvimento de software e o BDD é sua aplicação na camada mais externa do desenvolvimento (em comparação com o TDD, por exemplo, no nível da unidade).

Sumário

Em resumo, o BDD não o eleva dos problemas da ambiguidade da linguagem natural. No entanto, ajuda você a resolver esse problema através de dois pontos importantes: Concentrar-se em uma linguagem onipresente para reduzir as ambiguidades (não as eliminará totalmente, mas ajuda muito!) E forçando você a escrever executável especificações. O último ponto está ajudando a resolver problemas de ambiguidade principalmente porque esse é o ponto em que as ambiguidades começam a aparecer como problemas de outra maneira.

Quando algo é escrito em "linguagem natural", isso pode significar várias coisas:

• Isso é literalmente inglês. Como o inglês é um idioma muito ambíguo e impreciso, esse modo de entrada é insatisfatório no contexto do desenvolvimento de software.

• É inglês, mas termos relevantes são definidos com precisão. Essa linguagem é usada em documentos legais ou textos matemáticos.

• Esta é uma linguagem formal, mas a linguagem é modelada muito de perto após convenções de linguagem natural. Isso descreve todas as linguagens de programação, até certo ponto. Quanto mais inglesa for a linguagem formal, mais fácil será entender para leitores não treinados. Exemplos notáveis ​​de linguagens de programação com esse objetivo incluem COBOL e SQL: select id, name from persons where age > 18é imediatamente óbvio. A desvantagem desses idiomas é que você precisa entender o idioma formal para escrever o código de trabalho. Além disso, esses idiomas costumam ser muito detalhados.

DDD sugere que o projeto use uma linguagem onipresente para descrever o domínio. Este é essencialmente o caso 2: defina termos relevantes para que você possa se comunicar com precisão dentro da linguagem natural.

O pepino em si é o caso 3: uma linguagem formal que tem a intenção de ler muito próximo do inglês normal. Mais precisamente: pepino é uma estrutura que permite definir uma linguagem formal simples que pode ser usada para expressar requisitos / testes. O ponto aqui é que o mesmo documento representa os requisitos de linguagem natural e os testes executáveis ​​automaticamente, portanto os dois sempre estarão sincronizados. Você pode ler um cenário de pepino e verificar se ele expressa seus requisitos corretamente, sem precisar entender como tudo isso funciona.

Pepino funciona comparando o documento com trechos conhecidos da linguagem natural. Esses trechos devem ser definidos primeiro. Para escrever um cenário no Cucumber, você precisa estar ciente dos trechos disponíveis - o software não será lido. Esses trechos também são uma fonte de possíveis problemas: Quando você implementa o comportamento de um trecho de texto, seu código pode fazer algo ligeiramente diferente do que o texto do trecho sugere. É improvável que seja um problema se o mesmo trecho for usado várias vezes. Portanto, pepino é adequado para descrever regras de negócios que consistem em um conjunto menor de condições, ações e resultados. Outras estruturas de teste podem ser melhores se cada trecho for usado apenas uma ou duas vezes, por exemplo, porque a configuração de cada caso de teste é única.

@ Raghuram8892, o texto após as palavras-chave Given / When / Then / And deve corresponder ao "snippet"; caso contrário, a etapa falhará como indefinida ou "pendente". Como tal, cai diretamente no caso 3.

Em relação ao "inglês", pepino e seu idioma, o pepino é projetado para uso internacional. Você pode chamar o comando, cucumber --i18n helppara ver a lista de idiomas suportados no momento e cucumber --i18n $CODEas palavras-chave para um código de idioma específico. Por exemplo, cucumber --i18n eofornece as palavras-chave para esperanto.