Organizando histórias de JBehave

Question

Começamos a usar o JBEHAVE para testes de aceitação e eu estava me perguntando como as pessoas que o estão usando estão organizando a escrita de histórias e o armazenamento de arquivos da história. É apenas o desenvolvimento que está trabalhando neles no momento, então temos os arquivos da história armazenados na pasta Recursos ao lado do código Java para implementá -los.

Acho que minha pergunta real é como e onde você está armazenando seus arquivos de história e como isso funciona com o proprietário do produto ou as histórias de redação de controle de qualidade?

Answer 1

@Mrwiggles
Como o T0RX disse que você tem sorte de ter controle de qualidade para escrever histórias/cenários.
Chegando à sua pergunta:
Desenvolvimento de comportamento Incentiva você a começar a definir as histórias por meio de cenários que expressam o comportamento desejado em um formato textual.
JBEHAVE HISTÓRIAS que você pode ser executado configurando em maven (pom.xml).

Você pode fazer uma pasta para armazenar seus arquivos de história na estrutura do seu pacote, como abaixo:

Your_Project
      |
      |
      |--Source_Code
      |
      |--Stories
      |
      |--Testing
      |
      *pom.xml

Ao configurar suas histórias em Maven, toda vez que você cria o projeto, ele dará resultado com os resultados de histórias/cenários com sucesso e fracassados.
O controle de qualidade atualizará os cenários nas histórias de pastas, e o desenvolvedor implementará os cenários passo a passo, omitindo as etapas existentes (que já foram desenvolvidas e vieram em outros cenários).
O controle de qualidade simplesmente executa o cenário/história e ele descobrirá o resultado em um formato textual (compreensível).
Como abaixo:

Desenvolvimento orientado a comportamento nos níveis de teste.

Alguns dos recursos do JBehave concentram -se na organização fácil.

• Configuração baseada em anotação e etapas Especificações de classe
• Suporte à injeção de dependência, permitindo instâncias de configuração e etapas compostas através do seu contêiner favorito (Guice, PicoContainer, Spring).
• Relatórios de história extensível: Saídas histórias executadas em diferentes formatos baseados em arquivos legíveis por humanos (HTML, TXT, XML). Vista totalmente capaz de estilo.
• A geração automática de etapas pendentes para que a construção não seja quebrada por uma etapa ausente, mas tem opção de configurar a construção de quebra para etapas pendentes.
• Localização das histórias de usuários, permitindo que sejam escritas em qualquer idioma.
• Integração do IDE: as histórias podem ser executadas como JUnit testes ou outras estruturas de teste de unidade baseadas em anotação, fornecendo fácil integração com seu IDE favorito.
• Integração da formiga: permite que as histórias sejam executadas via tarefa de formiga
• Integração do Maven: permite que as histórias sejam executadas via plug -in maven na fase de construção fornecida

Answer 2

Se você tiver a sorte de ter o proprietário do produto ou as histórias de redação de controle de qualidade, provavelmente as deseja em uma área específica do seu repositório de código -fonte para que você possa controlar o acesso independentemente da sua fonte principal (e também fornecer mais flexibilidade quando as compilações de IC são acionado se você estiver fazendo isso).

Você provavelmente encontrará muito de vaivém para minimizar o número de novas etapas que os desenvolvedores precisam escrever (ou seja, pare-os usando dez maneiras diferentes de escrever a mesma etapa); portanto, também precisará correr com etapas pendentes que não falhando no cenário (que é o padrão fora da caixa).

Uma abordagem alternativa é que o proprietário de controle de qualidade/produto envia cenários aos desenvolvedores que os limpam antes de adicionar ao controle de origem, mas isso coloca o esforço de volta aos desenvolvedores.