teste de aceitação automatizado / BDD e fluxo de trabalho para projetar um sistema

O BDD, na sua essência, é uma metodologia de desenvolvimento de software com o objetivo de orientar (ou orientar) o código a partir de exemplos de como o sistema é usado. Não tem nada a dizer sobre a aparência real da interface do usuário (que pode ser considerada como um simples "controlador" para seu aplicativo e poderia, em teoria, ser facilmente trocada por uma API REST, um navegador-ui ou qualquer coisa através de qual o usuário pode interagir com o aplicativo). Portanto, a partir da interface do usuário pode ser bastante enganador se você tentar praticar o BDD.

Pense na sua interface do usuário como uma camada fina que não contém lógica de negócios e, em vez disso, concentre-se em direcionar as "entranhas" do aplicativo. Essa é a lógica que você descreve na etapa (3) do seu fluxo de trabalho.

Por exemplo, imagine que esse seja um aplicativo de compras e o comportamento final que você gostaria de conduzir é comprar um produto. Isso requer poder dar o comando do sistema para adicionar um produto a uma "cesta", podendo pagar por etc. "Adicionar Produto X ao Carrinho" e "Pagar pelo meu Carrinho" são comandos que você pode dar ao sistema independentemente da interface do usuário.

Mesmo se você já especificou a interface do usuário - você pode / deve identificar os comandos dados ao sistema. É essencial conceituar o sistema em termos de lógica de negócios para que você não se distraia com detalhes de como a interface do usuário funcionará (você pode pensar nisso mais tarde).

Cada um desses comandos identificados se torna o When no cenário Given/When/Then . A ação que é finalmente testada quando o pacote é executado.

Identifique as regras de negócios - elas ajudarão você a entender as condições prévias que precisam ser atendidas para cada comando para ter o resultado esperado. Digamos que você tenha uma regra de negócios sobre os clientes que recebem uma Torradeira gratuita em todos os Microondas quando uma venda está em andamento:

Background:
  Given the price of a microwave oven is £100
  And the price of a toaster is £10

Scenario: Customers get free toaster if they buy a microwave 
  Given the winter sale starts on Sun 31st Dec at 9am
  When I buy a microwave oven on Sun 31st Dec at 9am
  Then my basket should contain the following line items
    | Product        | Price |
    | Microwave oven | £100  |
    | Toaster        | £0    |

Scenario: Customers do not get free toaster if they buy a microwave before sale
  Given the winter sale starts on Sun 31st Dec at 9am
  When I buy a microwave oven on Sun 31st Dec at 8am
  Then my basket should contain the following line items
    | Product        | Price |
    | Microwave oven | £100  |
    | Toaster        | £10   |

Nesses cenários, você pode começar a escrever o código. Nas etapas determinadas, você configura os produtos com seus preços e a regra de vendas. Em sua etapa When , você executa a ação - chamando o código diretamente (desenvolvimento e feedback mais rápidos), chamando uma API ou automatizando o navegador real (o feedback mais lento e demorado) Em sua etapa Then , você afirma que o resultado aconteceu conforme o esperado - isso pode envolver a inspeção do conteúdo da persistência de dados e, provavelmente, a resposta do sistema ou da interface do usuário.

Construir o aplicativo dessa maneira força você a pensar bastante antes (a lógica de negócios), mas a codificação é mais fácil porque você simplesmente precisa fazer os cenários (que se tornam testes neste momento) passarem. Seu código é guiado literalmente pelos cenários / exemplos. / Quando eles passam você pode ter certeza de que o sistema funciona corretamente - vá e construa uma interface do usuário que permitirá aos clientes fazer o que os cenários dizem.

Esta é uma pergunta ampla sem resposta específica - você provavelmente criou uma desde postar a pergunta.

Você pode pensar em testes de aceitação mais o BDD como desenvolvimento vermelho-verde para cada nível do projeto. Em um mundo puro, você poderia escrever testes de aceitação de nível superior primeiro usando o BDD, sabendo que a funcionalidade não existe e que todos os testes vão falhar. Em seguida, você poderia escrever testes de estilo BDD gerais para cada um dos principais componentes ou subsistemas no aplicativo. À medida que cada subsistema é desenvolvido, os testes gerais do BDD são mais específicos. Em seguida, você usaria o desenvolvimento orientado a testes para criar os testes para a lógica de bastidores e as funções privadas à medida que você as implementa.

Pessoalmente, descobri que todos os níveis de BDD são úteis até certo ponto, mas é preciso uma equipe disciplinada para fazer isso do começo ao fim. O BDD também pode não ser apropriado para todos os projetos, dependendo dos requisitos de negócios, restrições de tempo, pessoal, orçamento, ad infinitum.

Eu costumo escrever testes BDD como aceitação para os endpoints do meu sistema WCF / MVC / WEBAPI .... desde que essas são histórias que o negócio se preocupa. Estou usando o SpecFlow para criar arquivos de recursos e cenários de critérios de aceitação. Então, no que diz respeito ao meu teste de MVC, criarei um arquivo de recurso que se parece com

Feature: High School Manamgement 
    In order to manage a list of high schools
    As a coach 
    I want to be able to create, edit or delete a high school

@web
Scenario: Navigate to the high school home page
    Given I am logged in as ''
    When I navigate to the page '/HighSchool'
    Then I should see a table named 'HighSchoolGrid'
        And I should see the 'Create High School' button

@web
Scenario: Navigate to high school create page
    Given I am logged in as ''
    When I navigate to the page '/HighSchool/Create'
    Then I should see the fields
    | Field               |
    | Name                |
    | Type                |
    | PhoneNumber         |
    | Mascot              |
    | AddressLine1        |
    | AddressLine2        |
    | AddressCity         |
    | AddressState        |
    | AddressZipCode      |
    | AddressZipExtension |
        And the required fields should be marked required  
        | Required Field |
        | Name           |
        | AddressState   |
        And I should see the form submit button 'Create'
        And I should see the 'Cancel' button

@web
Scenario: Submit Empty Create Form
    Given I am logged in as ''
    And I have navigated to the page '/HighSchool/Create'
    When I submit the form
    Then I should see the required fields highlighted
        | Required Field |
        | Name           |
        | AddressState   |
        And I should see the error message ''

@web
Scenario: Submit Form Successful
    Given I am logged in as ''
        And I have navigated to the page '/HighSchool/Create'
        And I have filled out the form as follows
            | Name      | Type | PhoneNumber    | Mascot  | AddressLine1  | AddressLine2 | AddressCity | AddressState | AddressZipCode | AddressZipExtension |
            | xxxxxxxxx |      | (215) 555-1212 | XXXXXXX| 1 Main Street |              | XXXXXXXXX| PA           | 18964          |                     |
    When I submit the form
    Then I should be redirected to '/HighSchool'
        And  I should see the success message 'xxxxxxxxx has been added'

Portanto, esses cenários são meus testes de aceitação, que são testes de integração que exercitam todo o sistema. Eu criei a tag @web para gerar uma instância do selenium webdriver para executar o site. Eu também criei uma tag @api que gira um HttpClient que depois publicará no endpoint do WebApi.

Assim como seu fluxo de trabalho atual, eu uso ui mock (s), ui-logic, ... para capturar um teste que um qa tester ou um parceiro de negócios possa executar. A outra coisa boa é que agora eu tenho testes de regressão automatizados para que, se meus requisitos mudarem quando eu executar meu conjunto de testes, eu agora veja uma falha para o requisito alterado. Eu posso criar um novo teste de BDD que captura essa alteração para que qualquer regressão com falha possa ser avaliada e removida se não for mais um teste válido. Isso também pode ajudá-lo a descobrir onde vários requisitos concorrem entre si.

Essa é realmente a extensão do verdadeiro teste de BDD / aceitação que eu faço.

Eu também tenho testes de unidade que espelham um pouco o estilo BDD, pois são expressos em uma sintaxe um pouco Gherkin. Começo com esta classe base de especificação para testes que encontrei de Jimmy Bogard em Los Techies.

public abstract class SpecificationBase
{
    [SetUp]
    public void SetUp()
    {
        Given();
        When();
    }

    protected virtual void Given() {}
    protected virtual void When() {}
}

public class ThenAttribute : TestAttribute {}

Então meus testes unitários seguem um padrão padrão. Veja minha resposta aqui para um exemplo de implementação da esta classe abstrata. Acho que isso me dá uma boa cobertura tanto na integração quanto no teste de unidade.