Desenvolvimento baseado em comportamento - Guia rápido
O Behavior Driven Development (BDD) é um processo de desenvolvimento de software que surgiu originalmente do Test Driven Development (TDD).
De acordo com Dan North, que é responsável pela evolução do BDD, “o BDD está usando exemplos em vários níveis para criar uma compreensão compartilhada e incerteza superficial para entregar software que importa”.
O BDD usa exemplos para ilustrar o comportamento do sistema que são escritos em uma linguagem legível e compreensível para todos os envolvidos no desenvolvimento. Esses exemplos incluem -
Convertido em especificações executáveis.
Usado como testes de aceitação.
BDD - Principais recursos
O Desenvolvimento Orientado ao Comportamento se concentra em -
Proporcionar um processo compartilhado e ferramentas compartilhadas que promovam a comunicação aos desenvolvedores de software, analistas de negócios e stakeholders para colaborar no desenvolvimento de software, com o objetivo de entregar produto com valor de negócio.
O que um sistema deve fazer e não como deve ser implementado.
Fornecendo melhor legibilidade e visibilidade.
Verificar não apenas o funcionamento do software, mas também se ele atende às expectativas do cliente.
Origem do BDD
O custo para corrigir um defeito aumenta em múltiplas vezes se o defeito não for detectado no momento certo e corrigido como e quando for detectado. Considere o seguinte exemplo.
Isso mostra que, a menos que os requisitos sejam obtidos corretamente, seria caro corrigir os defeitos resultantes da má compreensão dos requisitos em um estágio posterior. Além disso, o produto final pode não atender às expectativas do cliente.
A necessidade da hora é uma abordagem de desenvolvimento que -
Baseia-se nos requisitos.
Concentra-se nos requisitos ao longo do desenvolvimento.
Garante que os requisitos sejam atendidos.
Uma abordagem de desenvolvimento que pode cuidar dos requisitos mencionados acima é o BDD. Assim, Desenvolvimento Orientado por Comportamento -
Deriva exemplos de diferentes comportamentos esperados do sistema.
Permite escrever os exemplos em uma linguagem usando os termos do domínio de negócios para garantir o fácil entendimento por todos os envolvidos no desenvolvimento, incluindo os clientes.
Obtém os exemplos ratificados com o cliente de vez em quando por meio de conversas.
Concentra-se nos requisitos do cliente (exemplos) ao longo do desenvolvimento.
Usa exemplos como testes de aceitação.
Práticas BDD
As duas principais práticas de BDD são -
Especificação por Exemplo (SbE)
Desenvolvimento Orientado a Testes (TDD)
Especificação por Exemplo
A Especificação por Exemplo (SbE) usa exemplos em conversas para ilustrar as regras de negócios e o comportamento do software a ser construído.
A especificação por exemplo permite que os proprietários do produto, analistas de negócios, testadores e desenvolvedores eliminem mal-entendidos comuns sobre os requisitos de negócios.
Desenvolvimento Orientado a Testes
O Test Driven Development, no contexto do BDD, transforma exemplos em especificações executáveis legíveis por humanos.
Os desenvolvedores usam essas especificações como um guia para implementar incrementos de novas funcionalidades. Isso resulta em uma base de código enxuta e um conjunto de testes de regressão automatizados que mantêm os custos de manutenção baixos durante a vida útil do software.
Agile BDD
No desenvolvimento de software Agile, o método BDD é usado para chegar a um entendimento comum sobre as especificações pendentes.
As etapas a seguir são executadas no Agile BDD -
Os desenvolvedores e o product owner colaborativamente escrevem especificações pendentes em um editor de texto simples.
O proprietário do produto especifica os comportamentos que espera do sistema.
Os desenvolvedores
Preencha as especificações com esses detalhes de comportamento.
Faça perguntas com base em seu entendimento do sistema.
Os comportamentos atuais do sistema são considerados para verificar se o novo recurso interromperá algum dos recursos existentes.
Manifesto Ágil e BDD
O Manifesto Ágil afirma o seguinte -
Estamos descobrindo melhores maneiras de desenvolver software, fazendo isso e ajudando outros a fazê-lo. Por meio deste trabalho, chegamos a valorizar -
Individuals and interactions - sobre processos e ferramentas
Working software - sobre documentação abrangente
Customer collaboration - sobre negociação de contrato
Responding to change - acabou Seguindo um plano
Ou seja, embora haja valor nos itens à direita, valorizamos mais os itens à esquerda.
O BDD se alinha ao manifesto Agile da seguinte maneira -
| Manifesto Ágil | Alinhamento BDD |
|---|---|
| Indivíduos e interações sobre processos e ferramentas. | BDD é ter conversas. |
| software que trabalha sobre uma documentação completa. | O BDD se concentra em facilitar a criação de software de valor comercial. |
| Colaboração com o cliente na negociação do contrato. | O BDD foca em cenários baseados em ideias com comunicação contínua com o cliente conforme o desenvolvimento avança. Não é baseado em nenhuma promessa. |
| Respondendo à mudança seguindo um plano. | O BDD se concentra na comunicação e colaboração contínuas que facilitam a absorção de mudanças. |
Quando você olha para qualquer referência sobre Behavior Driven Development, você encontrará o uso de frases como “BDD é derivado de TDD”, “BDD e TDD”. Para saber como o BDD surgiu, por que se diz que ele é derivado do TDD e o que é BDD e TDD, é necessário entender o TDD.
Por que testar?
Para começar, vamos entrar nos fundamentos do teste. O objetivo do teste é garantir que o sistema construído esteja funcionando conforme o esperado. Considere o seguinte exemplo.
Conseqüentemente, por experiência, aprendemos que revelar um defeito à medida que ele é introduzido e consertá-lo imediatamente seria econômico. Portanto, há uma necessidade de escrever casos de teste em cada estágio de desenvolvimento e teste. Isso é o que nossas práticas de teste tradicionais nos ensinaram, que geralmente é denominado como Teste antecipado.
Essa abordagem de teste é denominada abordagem Teste-Último, pois o teste é feito após a conclusão de um estágio.
Desafios com a abordagem Test-Last
A abordagem Test-Last foi seguida por algum tempo nos projetos de desenvolvimento de software. No entanto, na realidade, com esta abordagem, como o teste tem que esperar até que o estágio específico seja concluído, muitas vezes é esquecido por causa de -
Os atrasos na conclusão da etapa.
Horários apertados.
Concentre-se na entrega no prazo, evitando os testes.
Além disso, na abordagem Teste-Último, o teste de unidade, que deveria ser feito pelos desenvolvedores, é frequentemente ignorado. Os vários motivos encontrados são baseados na mentalidade dos desenvolvedores -
Eles são desenvolvedores e não testadores.
O teste é de responsabilidade dos testadores.
Eles são eficientes na codificação e seu código não teria defeitos.
Isso resulta em -
Comprometimento com a qualidade do produto entregue.
Ter a responsabilidade pela qualidade apenas nos testadores.
Custos elevados na correção de defeitos, pós-entrega.
Incapacidade de obter a satisfação do cliente, o que também significaria a perda de novos negócios, afetando a credibilidade.
Esses fatores exigiram uma mudança de paradigma, para se concentrar nos testes. O resultado foi a abordagem Teste-Primeiro.
Abordagem Teste-Primeiro
A abordagem Test-First substitui a forma de desenvolvimento de dentro para fora (escrever código e depois testar) para fora para dentro (escrever teste e, em seguida, codificar).
Esta abordagem é incorporada às seguintes metodologias de desenvolvimento de software (que também são Ágeis) -
eXtreme Programming (XP)
THusa Drasgado Development (TDD).
Nessas metodologias, o desenvolvedor projeta e escreve os testes de unidade para um módulo de código antes de escrever uma única linha do módulo de código. O desenvolvedor então cria o módulo de código com o objetivo de passar no teste de Unidade. Assim, essas metodologias usam testes de unidade para conduzir o desenvolvimento.
O ponto fundamental para notar que o objetivo é o desenvolvimento baseado em testes.
Ciclo Red-Green-Refactor
O Desenvolvimento Orientado a Testes é usado para desenvolver o código guiado por testes de unidade.
Step 1 - Considere um módulo de código que deve ser escrito.
Step 2 - Escreva um teste
Step 3 - Faça o teste.
O teste falha, pois o código ainda não foi escrito. Portanto, a Etapa 2 é geralmente referida como escrever um teste para falhar.
Step 4 - Escreva o código mínimo possível para passar no teste.
Step 5- Execute todos os testes para garantir que todos eles sejam aprovados. Os testes de unidade são automatizados para facilitar esta etapa.
Step 6 - Refatorar.
Step 7 - Repita da Etapa 1 à Etapa 6 para o próximo módulo de código.
Cada ciclo deve ser muito curto e uma hora típica deve conter muitos ciclos.
Isso também é conhecido popularmente como o Red-Green-Refactor ciclo, onde -
Red - Escrever um teste que falha.
Green - Escrever código para passar no teste.
Refactor - Remova a duplicação e melhore o código para os padrões aceitáveis.
Etapas do processo TDD
As etapas de um processo TDD são ilustradas abaixo.
Vantagens do TDD
Os benefícios ou vantagens do Desenvolvimento Orientado a Testes são -
O desenvolvedor precisa entender primeiro qual deve ser o resultado desejado e como testá-lo antes de criar o código.
O código de um componente é concluído apenas quando o teste é aprovado e o código é refatorado. Isso garante o teste e a refatoração antes que o desenvolvedor passe para o próximo teste.
Como o conjunto de testes de unidade é executado após cada refatoração, o feedback de que cada componente ainda está funcionando é constante.
Os testes de unidade atuam como documentação viva que está sempre à altura dos dados.
Se um defeito for encontrado, o desenvolvedor cria um teste para revelar esse defeito e, em seguida, modifica o código para que o teste passe e o defeito seja corrigido. Isso reduz o tempo de depuração. Todos os outros testes também são executados e quando passam, garante que a funcionalidade existente não seja quebrada
O desenvolvedor pode tomar decisões de design e refatorar a qualquer momento e a execução dos testes garante que o sistema ainda está funcionando. Isso torna o software sustentável.
O desenvolvedor tem a confiança de fazer qualquer alteração, pois se a alteração afetar alguma funcionalidade existente, o mesmo é revelado executando os testes e os defeitos podem ser corrigidos imediatamente.
Em cada execução de teste sucessiva, todas as correções de defeitos anteriores também são verificadas e a repetição do mesmo defeito é reduzida.
Como a maioria dos testes é feita durante o próprio desenvolvimento, o teste antes da entrega é reduzido.
Desvantagens do TDD
O ponto de partida são as Estórias de Usuário, que descrevem o comportamento do sistema. Portanto, os desenvolvedores costumam enfrentar as seguintes questões -
Quando testar?
O que testar?
Como saber se uma especificação é atendida?
O código agrega valor ao negócio?
Equívocos sobre TDD
Os seguintes equívocos existem na indústria e precisam de esclarecimentos.
| Equívoco | Esclarecimento |
|---|---|
| TDD trata de testes e automação de testes. | TDD é uma metodologia de desenvolvimento que usa a abordagem Test-First. |
| O TDD não envolve nenhum projeto. | O TDD inclui análise crítica e design com base nos requisitos. O design surge durante o desenvolvimento. |
| TDD está apenas no nível da unidade. | O TDD pode ser usado nos níveis de integração e sistema. |
| O TDD não pode ser usado por projetos de teste tradicionais. | O TDD se tornou popular com a Extreme Programming e está sendo usado em outras metodologias Agile. No entanto, ele também pode ser usado em projetos de teste tradicionais. |
| TDD é uma ferramenta. | TDD é uma metodologia de desenvolvimento e, após cada novo teste de unidade passar, ele é adicionado ao Automation Test Suite, pois todos os testes precisam ser executados sempre que um novo código é adicionado ou o código existente é modificado e também após cada refatoração. Assim, as ferramentas de automação de teste que suportam TDD facilitam esse processo. |
| TDD significa entregar testes de aceitação aos desenvolvedores. | TDD não significa entregar testes de aceitação aos desenvolvedores. |
Aceitação TDD
O Desenvolvimento Orientado para o Teste de Aceitação (ATDD) define os Critérios de Aceitação e os Testes de Aceitação durante a criação das Estórias de Usuário, no início do desenvolvimento. ATDD se concentra na comunicação e entendimento comum entre os clientes, desenvolvedores e testadores.
As principais práticas em ATDD são as seguintes -
Discuta cenários do mundo real para construir uma compreensão compartilhada do domínio.
Use esses cenários para chegar aos critérios de aceitação.
Automatize os testes de aceitação.
Concentre o desenvolvimento nesses testes.
Use os testes como uma especificação ao vivo para facilitar a mudança.
Os benefícios de usar ATDD são os seguintes -
Os requisitos são inequívocos e sem lacunas funcionais.
Outros entendem os casos especiais que os desenvolvedores prevêem.
Os testes de Aceitação orientam o desenvolvimento.
TDD Vs BDD
De acordo com Dan North, os programadores normalmente enfrentam os seguintes problemas ao executar o Desenvolvimento Orientado a Testes -
Onde começar
O que testar e o que não testar
Quanto testar de uma só vez
Como chamar seus testes
Como entender por que um teste falha
A solução para todos esses problemas é o Desenvolvimento Orientado ao Comportamento. Ele evoluiu a partir das práticas ágeis estabelecidas e é projetado para torná-las mais acessíveis e eficazes para as equipes, iniciantes na entrega ágil de software. Com o tempo, o BDD cresceu para abranger o quadro mais amplo de análise ágil e teste de aceitação automatizado.
O principal difference between TDD and BDD é isso -
TDD descreve como o software funciona.
Por outro lado, BDD -
Descreve como o usuário final usa o software.
Promove colaboração e comunicação.
Enfatiza exemplos de comportamento do Sistema.
Visa as especificações executáveis derivadas dos exemplos
No TDD, o termo “Testes de Aceitação” é enganoso. Os testes de aceitação realmente representam o comportamento esperado do sistema. Nas práticas Agile, a colaboração de toda a equipe e as interações com o cliente e outras partes interessadas são enfatizadas. Isso deu origem à necessidade de utilização de termos que sejam facilmente compreendidos por todos os envolvidos no projeto.
TDD faz você pensar sobre o necessário Behavior e, portanto, o termo 'comportamento' é mais útil do que o termo ‘Test’. BDD é Test Driven Development com um vocabulário que se concentra no comportamento e não nos testes.
Nas palavras de Dan North, “descobri que a mudança do pensamento em testes para o pensamento em comportamento foi tão profunda que comecei a me referir ao TDD como BDD, ou Behavior Driven Development.” O TDD se concentra em como algo vai funcionar, o BDD se concentra em por que o construímos.
O BDD responde às seguintes perguntas frequentemente enfrentadas pelos desenvolvedores -
| Questão | Responda |
|---|---|
| Onde começar? | De fora para dentro |
| O que testar? | Histórias de usuários |
| O que não testar? | algo mais |
Essas respostas resultam na estrutura da história da seguinte maneira -
Story Framework
Como um [Role]
eu quero [Feature]
de modo a [Benefit]
Isso significa, 'Quando um Feature é executado, o resultado Benefit é para a pessoa que joga o Role.'
O BDD responde ainda às seguintes questões -
| Questão | Responda |
|---|---|
| Quanto custa para testar de uma só vez? | muito pouco focado |
| Como chamar seus testes? | modelo de frase |
| Como entender por que um teste falha | documentação |
Essas respostas resultam na estrutura de exemplo a seguir -
Example Framework
Given algum contexto inicial,
When um evento ocorre,
Then garantir alguns resultados.
Isso significa, 'começando com o contexto inicial, quando um determinado evento acontece, sabemos quais são os resultados should be. '
Assim, o exemplo mostra o comportamento esperado do sistema. Os exemplos são usados para ilustrar diferentes cenários do sistema.
História e Cenários
Vamos considerar a seguinte ilustração de Dan North sobre um sistema ATM.
História
As a cliente,
I want para retirar dinheiro de um caixa eletrônico,
so that Não preciso esperar na fila do banco.
Cenários
Existem dois cenários possíveis para esta história.
Scenario 1 - Conta com crédito
Given a conta está em crédito
And o cartão é válido
And o distribuidor contém dinheiro
When o cliente pede dinheiro
Then garantir que a conta seja debitada
And garantir que o dinheiro seja dispensado
And certifique-se de que o cartão seja devolvido
Scenario 2 - A conta está a descoberto após o limite de descoberto
Given a conta está a descoberto
And o cartão é válido
When o cliente pede dinheiro
Then garantir que uma mensagem de rejeição seja exibida
And garantir que o dinheiro não seja distribuído
And certifique-se de que o cartão seja devolvido
O evento é o mesmo em ambos os cenários, mas o contexto é diferente. Portanto, os resultados são diferentes.
Ciclo de Desenvolvimento
O Ciclo de Desenvolvimento do BDD é um outside-in aproximação.
Step 1- Escreva um exemplo de valor de negócios de alto nível (externo) (usando Cucumber ou RSpec / Capybara) que fica vermelho. (RSpec produz uma estrutura BDD na linguagem Ruby)
Step 2 - Escreva um exemplo RSpec de nível inferior (interno) para a primeira etapa de implementação que fica vermelho.
Step 3 - Implemente o código mínimo para passar esse exemplo de nível inferior, veja-o ficar verde.
Step 4 - Escreva o próximo exemplo de RSpec de nível inferior empurrando para passar na Etapa 1 que fica vermelho.
Step 5 - Repita as etapas Etapa 3 e Etapa 4 até que o exemplo de alto nível na Etapa 1 fique verde.
Note - Os seguintes pontos devem ser mantidos em mente -
Red/green state é um status de permissão.
Quando seus testes de baixo nível são verdes, você tem permissão para escrever novos exemplos ou refatorar a implementação existente. Você não deve, no contexto da refatoração, adicionar nova funcionalidade / flexibilidade.
Quando seus testes de baixo nível estão vermelhos, você tem permissão para escrever ou alterar o código de implementação apenas para tornar os testes existentes verdes. Você deve resistir ao impulso de escrever o código para passar em seu próximo teste, que não existe, ou implementar recursos que você possa considerar bons (o cliente não teria perguntado).
De acordo com Gojko Adzic, autor de 'Especificação por Exemplo', Especificação por Exemplo é um conjunto de padrões de processo que facilitam a mudança em produtos de software para garantir que o produto certo seja entregue com eficiência ”.
A Especificação por Exemplo é uma abordagem colaborativa para definir os requisitos e testes funcionais orientados a negócios para produtos de software com base na captura e ilustração de requisitos usando exemplos realistas em vez de declarações abstratas.
Especificação por exemplo - Visão geral
O objetivo da Especificação por Exemplo é focar no desenvolvimento e entrega de requisitos de negócios priorizados e verificáveis. Embora o conceito de Especificação por Exemplo em si seja relativamente novo, é simplesmente uma reformulação das práticas existentes.
Suporta um vocabulário conciso e muito específico conhecido como linguagem ubíqua que -
Habilita requisitos executáveis.
É usado por todos na equipe.
É criado por uma equipe multifuncional.
Capta a compreensão de todos.
A especificação por exemplo pode ser usada como uma entrada direta na construção de testes automatizados que refletem o domínio do negócio. Portanto, o foco da Especificação por Exemplo é construir o produto certo e construir o produto da maneira certa.
Objetivo da Especificação por Exemplo
O objetivo principal da Especificação por Exemplo é construir o produto certo. Ele se concentra no entendimento compartilhado, estabelecendo assim uma única fonte de verdade. Ele permite a automação dos critérios de aceitação para que o foco seja a prevenção de defeitos, e não a detecção de defeitos. Também promove testes precoces para encontrar os defeitos precocemente.
Uso de SbE
Especificação por exemplo é usada para ilustrar o comportamento esperado do sistema que descreve o valor do negócio. A ilustração é feita por meio de exemplos concretos e reais. Esses exemplos são usados para criar requisitos executáveis que são -
Testável sem tradução.
Capturado na documentação ao vivo.
A seguir estão as razões pelas quais usamos exemplos para descrever especificações particulares -
Eles são mais fáceis de entender.
Eles são mais difíceis de interpretar mal.
Vantagens do SbE
As vantagens de usar a Especificação por Exemplo são -
Maior qualidade
Desperdício reduzido
Risco reduzido de defeitos de produção
Esforço focado
As alterações podem ser feitas com mais segurança
Envolvimento de negócios aprimorado
Aplicações de SbE
Especificação por exemplo encontrar aplicativos em -
Ou negócio complexo ou organização complexa.
Não funciona bem para problemas puramente técnicos.
Não funciona bem para produtos de software focados em IU.
Pode ser aplicado a sistemas legados também.
SbE e Teste de Aceitação
As vantagens da Especificação por Exemplo em termos de teste de Aceitação são -
Uma única ilustração é usada para requisitos detalhados e testes
O andamento do projeto é em termos de testes de aceitação -
Cada teste serve para testar um comportamento.
Um teste está passando por um comportamento ou não.
Um teste de aprovação representa que o comportamento específico foi concluído.
Se um projeto que requer 100 comportamentos para ser concluído tem 60 comportamentos concluídos, ele está 60% concluído.
Os testadores mudam da correção de defeitos para a prevenção de defeitos e contribuem para o design da solução.
A automação permite a compreensão instantânea do impacto de uma mudança de requisito na solução.
Especificação por exemplo - O que isso significa para diferentes funções
O objetivo da Especificação por Exemplo é promover a colaboração de todos na equipe, incluindo o cliente em todo o projeto para entregar valor de negócio. Todos, para melhor compreensão, usam o mesmo vocabulário.
| Função | Uso de SbE |
|---|---|
| Analista de negócios |
|
| Desenvolvedor |
|
| Testador |
|
| Todos |
|
SbE - Um Conjunto de Padrões de Processo
Como vimos no início deste capítulo, a Especificação por Exemplo é definida como um conjunto de padrões de processo que facilitam a mudança em produtos de software para garantir que o produto certo seja entregue com eficiência.
Os padrões de processo são -
Especificação colaborativa
Ilustrando especificações usando exemplos
Refinando a especificação
Exemplos de automação
Validando freqüentemente
Documentação viva
Especificação Colaborativa
Os objetivos da especificação colaborativa são -
Faça com que as várias funções em uma equipe tenham um entendimento comum e um vocabulário compartilhado.
Envolva todos no projeto para que possam contribuir com suas diferentes perspectivas sobre um recurso.
Garanta a comunicação compartilhada e a propriedade dos recursos.
Esses objetivos são atendidos em um workshop de especificações também conhecido como Reunião dos Três Amigos. Os Três Amigos são BA, QA e o desenvolvedor. Embora existam outras funções no projeto, esses três seriam responsáveis e responsáveis desde a definição até a entrega dos recursos.
During the meeting −
O Analista de Negócios (BA) apresenta os requisitos e testes para um novo recurso.
Os três Amigos (BA, Desenvolvedor e QA) discutem o novo recurso e revisam as especificações.
O QA e o desenvolvedor também identificam os requisitos ausentes.
Os três amigos
Utilize um modelo compartilhado usando uma linguagem onipresente.
Use vocabulário de domínio (um glossário é mantido, se necessário).
Procure diferenças e conflitos.
Não pule para os detalhes de implementação neste momento.
Chegue a um consenso sobre se um recurso foi especificado o suficiente.
Um senso comum de requisitos e propriedade de teste facilita as especificações de qualidade
Os requisitos são apresentados como cenários, que fornecem requisitos explícitos e inequívocos. Um cenário é um exemplo do comportamento do sistema da perspectiva dos usuários.
Ilustrando a Especificação usando Exemplos
Os cenários são especificados usando a estrutura Dado-Quando-Então para criar uma especificação testável -
Given <alguma pré-condição>
And <pré-condições adicionais> Optional
When <ocorre uma ação / gatilho>
Then <alguma pós-condição>
And <condições adicionais de postagem> Optional
Esta especificação é um exemplo de comportamento do sistema. Também representa um critério de aceitação do sistema.
A equipe discute os exemplos e o feedback é incorporado até que haja um acordo de que os exemplos cobrem o comportamento esperado do recurso. Isso garante uma boa cobertura de teste.
Refinando a Especificação
Para refinar uma especificação,
Seja preciso ao escrever os exemplos. Se um exemplo se tornar complexo, divida-o em exemplos mais simples.
Concentre-se na perspectiva do negócio e evite detalhes técnicos.
Considere as condições positivas e negativas.
Siga o vocabulário específico do domínio.
Discuta os exemplos com o cliente.
Escolha conversas para fazer isso.
Considere apenas os exemplos nos quais o cliente está interessado. Isso permite a produção apenas do código necessário e evita cobrir todas as combinações possíveis, que podem não ser necessárias
Para garantir que o cenário seja aprovado, todos os casos de teste desse cenário devem ser aprovados. Portanto, aprimore as especificações para torná-las testáveis. Os casos de teste podem incluir vários intervalos e valores de dados (casos limite e de canto), bem como diferentes regras de negócios, resultando em alterações nos dados.
Especifique regras de negócios adicionais, como cálculos complexos, manipulação / transformação de dados, etc.
Inclui cenários não funcionais (por exemplo, desempenho, carga, usabilidade, etc.) como Especificação por Exemplo
Exemplos de automação
A camada de automação precisa ser mantida muito simples - apenas a fiação da especificação para o sistema em teste. Você pode usar uma ferramenta para o mesmo.
Realize a automação de teste usando Domain Specific Language (DSL) e mostre uma conexão clara entre entradas e saídas. Concentre-se na especificação e não no script. Certifique-se de que os testes são precisos, fáceis de entender e testáveis.
Validando Freqüentemente
Inclua validação de exemplo em seu pipeline de desenvolvimento com cada mudança (adição / modificação). Existem muitas técnicas e ferramentas que podem (e devem) ser adotadas para ajudar a garantir a qualidade de um produto. Eles giram em torno de três princípios-chaveTest Early, Test Well e Test Often.
Execute os testes com freqüência para que você possa identificar os elos fracos. Os exemplos que representam os comportamentos ajudam a rastrear o progresso e um comportamento é considerado concluído somente após a aprovação no teste correspondente.
Documentação Viva
Mantenha as especificações tão simples e curtas quanto possível. Organize as especificações e desenvolva-as à medida que o trabalho avança. Torne a documentação acessível para todos na equipe.
Especificação por etapas de processo de exemplo
A ilustração mostra as etapas do processo em Especificação por exemplo.
Antipadrões
Os antipadrões são certos padrões no desenvolvimento de software considerados uma má prática de programação. Ao contrário dos padrões de design, que são abordagens comuns para problemas comuns, que foram formalizados e geralmente considerados uma boa prática de desenvolvimento, os antipadrões são o oposto e são indesejáveis
Os antipadrões dão origem a vários problemas.
| Antipadrão | Problemas |
|---|---|
| Sem colaboração |
|
| Desconheço quando o código é concluído |
|
| Exemplos muito detalhados ou muito centrados na IU |
|
| Esforço subestimado necessário |
|
Solução para os problemas - Qualidade
A qualidade pode ser garantida observando os anti-padrões. Para minimizar os problemas criados por anti-padrões, você deve -
Reúna-se para especificar usando exemplos.
Limpe e melhore os exemplos.
Escreva um código que satisfaça os exemplos
Automatize os exemplos e implante.
Repita a abordagem para cada história de usuário.
Para resolver os problemas devido a anti-padrões significa adesão a -
Collaboration.
Focando em quê.
Foco nos negócios.
Esteja preparado.
Vamos entender o que cada uma das opções acima significa.
Colaboração
Em colaboração -
Empresários, desenvolvedores e testadores fornecem informações a partir de suas próprias perspectivas.
Exemplos automatizados provam que a equipe construiu a coisa certa.
O processo é mais valioso do que os próprios testes.
Focando no que
Você deve se concentrar na questão - 'o quê'. Enquanto se concentra em 'o quê' -
Não tente cobrir todos os casos possíveis.
Não se esqueça de usar diferentes tipos de testes.
Mantenha os exemplos o mais simples possível.
Os exemplos devem ser facilmente compreensíveis pelos usuários do sistema.
As ferramentas não devem desempenhar um papel importante nas oficinas.
Foco nos negócios
Para focar no negócio -
Mantenha as especificações na intenção do negócio.
Inclua negócios na criação e revisão de especificações.
Oculte todos os detalhes na camada de automação.
Esteja preparado
Esteja preparado para o seguinte -
Os benefícios não são imediatamente aparentes, mesmo quando as práticas da equipe são alteradas.
Apresentar o SbE é um desafio.
Requer tempo e investimentos.
O teste automatizado não é gratuito.
Ferramentas
O uso de ferramentas não é obrigatório para a Especificação por Exemplo, embora na prática várias ferramentas estejam disponíveis. Existem casos que são bem-sucedidos seguindo a Especificação por Exemplo, mesmo sem usar uma ferramenta.
As seguintes ferramentas suportam Especificação por Exemplo -
Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog
As equipes de desenvolvimento geralmente têm uma ideia errada de que o BDD é uma estrutura de ferramenta. Na realidade, o BDD é uma abordagem de desenvolvimento em vez de uma estrutura de ferramenta. No entanto, como no caso de outras abordagens de desenvolvimento, também existem ferramentas para BDD.
Várias ferramentas BDD estão em uso para diferentes plataformas e linguagens de programação. Eles são -
Pepino (estrutura Ruby)
SpecFlow (framework .NET)
Behave (framework Python)
JBehave (estrutura Java)
JBehave Web (estrutura Java com integração Selenium)
Alface (estrutura Python)
Concordion (estrutura Java)
Behat (framework PHP)
Kahlan (framework PHP)
DaSpec (estrutura JavaScript)
Jasmine (estrutura JavaScript)
Cucumber-js (estrutura JavaScript)
Squish GUI Tester (BDD GUI Testing Tool para JavaScript, Python, Perl, Ruby e Tcl)
Spock (estrutura Groovy)
Yadda (suporte à linguagem Gherkin para estruturas como Jasmine (estrutura JavaScript))
Pepino
Cucumber é uma ferramenta gratuita para especificações executáveis usada globalmente. Cucumber permite que as equipes de desenvolvimento de software descrevam como o software deve se comportar em texto simples. O texto é escrito em uma linguagem de domínio específico legível para negócios e serve como documentação, testes automatizados e ajuda ao desenvolvimento, tudo em um único formato. Você pode usar mais de quarenta idiomas diferentes (inglês, chinês, etc.) com o Cucumber.
Pepino - Características principais
As principais características do Cucumber são as seguintes -
O pepino pode ser usado para especificações executáveis, automação de teste e documentação viva.
Cucumber trabalha com Ruby, Java, NET, Flex ou aplicações web escritas em qualquer linguagem.
Cucumber oferece suporte a testes mais sucintos em tabelas - semelhante ao que o FIT faz.
A Cucumber revolucionou o Ciclo de Vida de Desenvolvimento de Software ao combinar requisitos, testes automatizados e documentação em um coeso: especificações executáveis de texto simples que validam o software.
SpecFlow
SpecFlow é uma ferramenta BDD para a plataforma .NET. SpecFlow é um projeto de código aberto. O código-fonte está hospedado no GitHub.
SpecFlow usa a sintaxe do Gherkin para recursos. O formato Gherkin foi introduzido pelo Cucumber e também é usado por outras ferramentas. A linguagem Gherkin é mantida como um projeto no GitHub -https://github.com/cucumber/gherkin
comporte-se
Behave é usado para o framework Python.
O Behave funciona com três tipos de arquivos armazenados em um diretório chamado “recursos” -
arquivos de recursos com seus cenários de comportamento.
Diretório "etapas" com implementações de etapas do Python para os cenários.
Optionally, some environmental controls (code to run before and after steps, scenarios, features or the whole shooting match).
Behave features are written using Gherkin (with some modifications) and are named “name.feature”.
The tags attached to a feature and scenario are available in the environment functions via the “feature” or “scenario” object passed to them. On those objects there is an attribute called “tags” which is a list of the tag names attached, in the order they are found in the features file.
Modifications to the Gherkin Standard −
Behave can parse standard Gherkin files and extends Gherkin to allow lowercase step keywords because these can sometimes allow more readable feature specifications
Lettuce
Lettuce is a very simple BDD tool based on Cucumber. It can execute plain-text functional descriptions as automated tests for Python projects. Lettuce aims the most common tasks on BDD.
Concordion
Concordion is an open source tool for automating Specification by Example for Java Framework.
While the core features are simple, the Powerful extension framework API allows you to add functionality, such as using Excel spreadsheets as specifications, adding screenshots to the output, displaying logging information, etc.
Concordion lets you write the specifications in normal language using paragraphs, tables and proper punctuation and the structured Language using Given/When/Then is not necessary.
Concordion has been ported to other languages including −
C# (Concordion.NET)
Python (PyConcordion)
Ruby (Ruby-Concordion)
Cucumber is a tool that supports Executable specifications, Test automation, and Living documentation.
Behavior Driven Development expands on Specification by Example. It also formalizes the Test-Driven Development best practices, in particular, the perspective of working from the outside-in. The development work is based on executable specifications.
The key features of executable specifications are as follows −
Executable Specifications are −
Derived from examples, that represent the behaviors of the system.
Written with collaboration of all involved in the development, including business and stakeholders.
Based on acceptance criterion.
Acceptance tests that are based on the executable specifications are automated.
A shared, ubiquitous language is used to write the executable specifications and the automated tests such that −
Domain specific terminology is used throughout the development.
Everyone, including the customers and the stakeholders speak about the system, its requirements and its implementation, in the same way.
The same terms are used to discuss the system present in the requirements, design documents, code, tests, etc.
Anyone can read and understand a requirement and how to generate more requirements.
Changes can be easily accommodated.
Live documentation is maintained.
Cucumber helps with this process since it ties together the executable specifications with the actual code of the system and the automated acceptance tests.
The way it does this is actually designed to get the customers and developers working together. When an acceptance test passes, it means that the specification of the behavior of the system that it represents has been implemented correctly.
Typical Cucumber Acceptance Test
Consider the following example.
Feature − Sign up
Sign up should be quick and friendly.
Scenario − Successful sign up
New users should get a confirmation e-mail and be greeted personally.
Given I have chosen to sign up.
When I sign up with valid details.
Then I should receive a confirmation email.
And I should see a personalized greeting message.
From this example, we can see that −
Acceptance tests refer to Features.
Features are explained by Scenarios.
Scenarios consist of Steps.
The specification is written in a natural language in a plain text file, but it is executable.
Working of Cucumber
Cucumber is a command line tool that processes text files containing the features looking for scenarios that can be executed against your system. Let us understand how Cucumber works.
It makes use of a bunch of conventions about how the files are named and where they are located (the respective folders) to make it easy to get started.
Cucumber lets you keep specifications, automated tests and documentation in the same place.
Each scenario is a list of steps that describe the pre-conditions, actions, and post-conditions of the scenario; if each step executes without anyberror, the scenario is marked as passed.
At the end of a run, Cucumber will report how many scenarios passed.
If something fails, it provides information about what failed so that the developer can progress.
In Cucumber, Features, Scenarios, and Steps are written in a Language called Gherkin.
Gherkin is plain-text English (or one of 60+ other languages) with a structure. Gherkin is easy to learn and its structure allows you to write examples in a concise manner.
Cucumber executes your files that contain executable specifications written in Gherkin.
Cucumber needs Step Definitions to translate plain-text Gherkin Steps into actions that will interact with the system.
When Cucumber executes a step in a scenario, it will look for a matching step definition to execute.
A Step Definition is a small piece of code with a pattern attached to it.
The pattern is used to link the Step Definition to all the matching steps, and the code is what Cucumber will execute when it sees a Gherkin step.
Each step is accompanied by a Step Definition.
Most steps will gather input and then delegate to a framework that is specific to your application domain in order to make calls on your framework.
Cucumber supports over a dozen different software platforms. You can choose the Cucumber implementation that works for you. Every Cucumber implementation provides the same overall functionality and they also have their own installation procedure and platform-specific functionality.
Mapping Steps and Step Definitions
The key to Cucumber is the mapping between Steps and Step Definitions.
Cucumber Implementations
Given below are Cucumber implementations.
|
Ruby/JRuby |
|
JRuby (using Cucumber-JVM) |
|
Java |
|
Groovy |
|
.NET (using SpecFlow) |
|
JavaScript |
|
|
JavaScript (using Cucumber-JVM and Rhino) |
|
Clojure |
|
Gosu |
|
Lua |
|
PHP (using Behat) |
|
Jython |
|
C++ |
|
Tcl |
Framework Integration
Given below are Framework implementations.
|
Ruby on Rails |
|
Selenium |
|
PicoContainer |
|
Spring Framework |
|
Watir |
Gherkin is a language, which is used to write Features, Scenarios, and Steps. The purpose of Gherkin is to help us write concrete requirements.
To understand what we mean by concrete requirements, consider the following example −
Customers should be prevented from entering invalid credit card details.
If a customer enters a credit card number that is not exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits.
The latter has no ambiguity and avoids errors and is much more testable.
Gherkin is designed to create requirements that are more concrete. In Gherkin, the above example looks like −
Feature
Feedback when entering invalid credit card details Feature Definition
In user testing, we have seen many people who make mistakes Documentation
Background True for all Scenarios Below
Given I have chosen an item to buy,
And I am about to enter my credit card number
Scenario − Credit card number too shortScenario Definition
When I enter a card number that is less than 16 digits long
And all the other details are correct
And I submit the formSteps
Then the form should be redisplayed
And I should see a message advising me of the correct number of digits
Gherkin Format and Syntax
Gherkin files are plain text Files and have the extension .feature. Each line that is not blank has to start with a Gherkin keyword, followed by any text you like. The keywords are −
Feature
Scenario
Given, When, Then, And, But (Steps)
Background
Scenario Outline
Examples
""" (Doc Strings)
| (Data Tables)
@ (Tags)
# (Comments)
*
Feature
The Feature keyword is used to describe a software feature, and to group the related scenarios. A Feature has three basic elements −
The keyword – Feature.
The name of the feature, provided on the same line as the Feature keyword.
An optional (but highly recommended) description that can span multiple lines i.e. all the text between the line containing the keyword Feature, and a line that starts with Scenario, Background, or Scenario Outline.
In addition to a name and a description, Features contain a list of scenarios or scenario outlines, and an optional background.
É convencional nomear um .featurearquivo pegando o nome do elemento, convertendo-o em minúsculas e substituindo os espaços por sublinhados. Por exemplo,
feedback_when_entering_invalid_credit_card_details.featurePara identificar recursos em seu sistema, você pode usar o que é conhecido como “modelo de injeção de recursos”.
Descrições
Algumas partes dos documentos Gherkin não precisam começar com uma palavra-chave.
Nas linhas que seguem um recurso, cenário, esboço de cenário ou exemplos, você pode escrever o que quiser, desde que nenhuma linha comece com uma palavra-chave. Esta é a maneira de incluir Descrições.
Cenário
Para expressar o comportamento do seu sistema, você anexa um ou mais cenários a cada recurso. É comum ver 5 a 20 cenários por recurso para especificar completamente todos os comportamentos em torno desse recurso.
Os cenários seguem o seguinte padrão -
Descreva um contexto inicial
Descreva um evento
Descreva um resultado esperado
Começamos com um contexto, descrevemos uma ação e verificamos o resultado. Isso é feito com etapas. Gherkin fornece três palavras-chave para descrever cada um dos contextos, ações e resultados como etapas.
Given - Estabelecer contexto
When - Executar ação
Then - Verifique o resultado
Essas palavras-chave fornecem legibilidade do cenário.
Example
Scenario - Retire dinheiro da conta.
Given Tenho $ 100 em minha conta.
When Eu solicito $ 20.
Then $ 20 devem ser dispensados.
Se houver vários Given ou When etapas abaixo umas das outras, você pode usar And ou But. Eles permitem que você especifique cenários em detalhes.
Example
Scenario - Tentativa de retirada com cartão roubado.
Given Tenho $ 100 em minha conta.
But meu cartão é inválido.
When Eu solicito $ 50.
Then meu cartão não deve ser devolvido.
And Eu deveria ser informado para entrar em contato com o banco.
Ao criar cenários, lembre-se de que 'cada cenário deve fazer sentido e poder ser executado independentemente de qualquer outro cenário' '. Isso significa -
Você não pode ter a condição de sucesso de um cenário dependendo do fato de que algum outro cenário foi executado antes dele.
Cada cenário cria seu contexto particular, executa uma coisa e testa o resultado.
Esses cenários fornecem os seguintes benefícios -
Os testes serão mais simples e fáceis de entender.
Você pode executar apenas um subconjunto de seus cenários e não precisa se preocupar com a quebra de seu conjunto de teste.
Dependendo do seu sistema, você pode executar os testes em paralelo, reduzindo o tempo necessário para executar todos os seus testes.
Esboço do cenário
Se você tiver que escrever cenários com várias entradas ou saídas, pode acabar criando vários cenários que diferem apenas por seus valores. A solução é usar o esboço do cenário. Para escrever um esboço do cenário,
As variáveis nas etapas do esboço do cenário são marcadas com <e>.
Os vários valores para as variáveis são fornecidos como exemplos em uma tabela.
Example
Suponha que você esteja escrevendo um recurso para adicionar dois números em uma calculadora.
Feature - Adicionar.
Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input | output |
| 2+2 | 4 |
| 98+1 | 99 |
| 255+390 | 645 |Uma seção de esboço de cenário é sempre seguida por uma ou mais seções de exemplos, que são um contêiner para uma tabela. A tabela deve ter uma linha de cabeçalho correspondente às variáveis nas etapas de esboço do cenário. Cada uma das linhas abaixo criará um novo cenário, preenchendo os valores das variáveis
SpecFlow é um projeto de código aberto. O código-fonte está hospedado no GitHub. Os arquivos de recurso usados por SpecFlow para armazenar um critério de aceitação para recursos (casos de uso, histórias de usuário) em seu aplicativo são definidos usando a sintaxe Gherkin.
O formato Gherkin foi introduzido pelo Cucumber e também é usado por outras ferramentas. A linguagem Gherkin é mantida como um projeto no GitHub -https://github.com/cucumber/gherkin
Elementos de recurso e SpecFlow
Os principais recursos dos elementos de recursos são -
O elemento feature fornece um cabeçalho para o arquivo feature. O elemento de recurso inclui o nome e uma descrição de alto nível do recurso correspondente em seu aplicativo.
SpecFlow gera uma classe de teste de unidade para o elemento de recurso, com o nome da classe derivado do nome do recurso.
SpecFlow gera testes de unidade executáveis dos cenários que representam critérios de aceitação.
Um arquivo de recurso pode conter vários cenários usados para descrever os testes de aceitação do recurso.
Os cenários têm um nome e podem consistir em várias etapas de cenário.
SpecFlow gera um método de teste de unidade para cada cenário, com o nome do método derivado do nome do cenário.
Várias etapas de cenário
Os cenários podem ter várias etapas de cenário. Existem três tipos de etapas que definem as pré-condições, ações ou etapas de verificação, que constituem o teste de aceitação.
Os diferentes tipos de etapas começam com o Given, When ou Then palavras-chave respectivamente e etapas subsequentes do mesmo tipo podem ser vinculadas usando o And e But palavras-chave.
A sintaxe do Gherkin permite qualquer combinação desses três tipos de etapas, mas um cenário geralmente tem blocos distintos de Given, When e Then afirmações.
As etapas do cenário são definidas usando texto e podem ter uma tabela adicional chamada DataTable ou texto de várias linhas chamado argumentos DocString.
As etapas do cenário são a principal maneira de executar qualquer código personalizado para automatizar o aplicativo.
SpecFlow gera uma chamada dentro do método de teste de unidade para cada etapa do cenário. A chamada é executada pelo tempo de execução SpecFlow que executará a definição da etapa correspondente à etapa do cenário.
A correspondência é feita em tempo de execução, portanto, os testes gerados podem ser compilados e executados mesmo se a vinculação ainda não tiver sido implementada.
Você pode incluir tabelas e argumentos de várias linhas nas etapas do cenário. Eles são usados pelas definições de etapa e são passados como tabelas adicionais ou argumentos de string.
Tag
Tags são marcadores que podem ser atribuídos a recursos e cenários. Atribuir uma tag a um recurso é equivalente a atribuir a tag a todos os cenários no arquivo de recurso. Um nome de tag com uma marca @ à esquerda.
Se suportado pela estrutura de teste de unidade, SpecFlow gera categorias a partir das tags.
O nome da categoria gerada é igual ao nome da tag, mas sem o @ inicial.
Você pode filtrar e agrupar os testes a serem executados usando essas categorias de teste de unidade. Por exemplo, você pode marcar testes cruciais com @important e, em seguida, executar esses testes com mais frequência.
Elementos de Fundo
O elemento de linguagem de fundo permite especificar uma pré-condição comum para todos os cenários em um arquivo de recurso
A parte do plano de fundo do arquivo pode conter uma ou mais etapas do cenário que são executadas antes de quaisquer outras etapas dos cenários.
SpecFlow gera um método a partir dos elementos de plano de fundo que é chamado de todos os testes de unidade gerados para os cenários.
Esboços do cenário
Os contornos do cenário podem ser usados para definir testes de aceitação baseados em dados. O esboço do cenário sempre consiste em uma especificação de modelo de cenário (um cenário com marcadores de posição de dados usando a sintaxe <placeholder>) e um conjunto de exemplos que fornecem valores para os marcadores de posição
Se a estrutura de teste de unidade suportar, SpecFlow gera testes baseados em linha a partir de contornos de cenário.
Caso contrário, ele gera um método lógico de teste de unidade parametrizado para um esboço de cenário e um método de teste de unidade individual para cada conjunto de exemplos.
Para melhor rastreabilidade, os nomes dos métodos de teste de unidade gerados são derivados do título do esboço do cenário e do primeiro valor dos exemplos (primeira coluna da tabela de exemplos).
Portanto, é uma boa prática escolher um parâmetro exclusivo e descritivo como a primeira coluna no conjunto de exemplos.
Como a sintaxe do Gherkin exige que todas as colunas de exemplo tenham marcadores de posição correspondentes no esboço do cenário, você pode até introduzir uma coluna arbitrária nos conjuntos de exemplos usados para nomear os testes com mais legibilidade.
SpecFlow executa a substituição do marcador como uma fase separada antes de corresponder às ligações da etapa.
A implementação e os parâmetros nas ligações da etapa são, portanto, independentes de serem executados por meio de um cenário direto ou de um esboço de cenário.
Isso permite que você especifique mais tarde exemplos adicionais nos testes de aceitação sem alterar as ligações da etapa.
Comentários
Você pode adicionar linhas de comentários aos arquivos de feições em qualquer lugar, iniciando a linha com #. No entanto, tenha cuidado, pois os comentários em sua especificação podem ser um sinal de que os critérios de aceitação foram especificados incorretamente. SpecFlow ignora linhas de comentários.