Desenvolvimento baseado em comportamento - SpecFlow

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 feature 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 ​​a partir de 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 uma forma primária 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 ligação ainda não foi implementada.

  • Você pode incluir tabelas e argumentos de várias linhas nas etapas do cenário. Eles são usados ​​pelas definições de etapas 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 um @ denota tag à 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 qualquer outra etapa dos cenários.

  • SpecFlow gera um método a partir dos elementos de segundo plano que é chamado de todos os testes de unidade gerados para os cenários.

Esboços de 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 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 único 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 de etapas 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 suas especificações podem ser um sinal de que os critérios de aceitação foram especificados incorretamente. SpecFlow ignora linhas de comentários.