As especificações de escrita - asserções ou hipóteses de teste - geralmente são ignoradas nos cursos de TDD, pois há pouca programação.
No entanto, eles são muito importantes.
Eles determinam como e quais testes serão gravados e também determinam como será fácil corrigir a falha. Eles quase não requerem tempo para implementação. Eles são os primeiros que conectam o usuário da história e o código e o primeiro que mostra a falha do código de teste. Eles também são os que nos protegem adicionalmente de erros no código do próprio teste.
Como poderíamos melhorar nossas declarações?
Primeiro, as
especificações devem estar relacionadas à história do usuário em termos . Se o usuário da história usar o termo "logon", a declaração não poderá alterar esse termo para autenticar / autorizar / validar. Se a história não for bem escrita, troque-a.
Em segundo lugar, a
especificação deve conter explicitamente o nome do componente que eles descrevem. Isso indica a área de teste e sinaliza um erro, se de repente a águia-pescadora incluir frequentemente alguns componentes inesperados.
O script válido é bem combinado com o princípio da responsabilidade Única, portanto o nome do componente deve corresponder à descrição do teste. Se houver muitos cenários válidos, provavelmente o componente tem muita responsabilidade.
Além disso, um cenário, como regra, descreve um evento de interface do usuário ou algum tipo de padrão. Bons candidatos ao nome do componente podem conter o nome do padrão: Validador, Estratégia, Construtor, Transformador, Controlador, etc. Ou nome do evento: remetente, login, ReadonlyOrderView etc. I.e. dependendo do nome do componente, os valores de entrada e saída da função principal da classe devem ser definidos. Nomes incorretos: muito abstratos (Serviço, Componente, Auxiliar, Utilitário) e duplos (ValidatorAndRenderer).
Terceiro, as
especificações devem declarar explicitamente as condições .
Ruim:
@Test public void testValidatePassword(){}
Melhor:
@Test public void loginController_whenValidUsername_andValidPassword_shouldLogUserIn(){}
Não precisamos chamar essa função de outro local; portanto, nomes muito longos são válidos. Se o número de condições no teste não se encaixar na linha, talvez você deva alterar a estrutura do componente.
Para testes em javascript, a mesma coisa, mas você pode colocar as condições lá, é mais conveniente.
describe('login UI component', () => { describe('when username provided', () => { describe('when valid password', () => { it('should log user in', () => { ... }); }); }); });
As condições explícitas são mais fáceis de ler e
encontrar ausentes .
Além disso, se a condição não corresponder ao código de teste escrito, é fácil corrigir o código.
Uma boa descrição é, em geral, um substituto para documentação e comentários de código. É abstrato, não depende da estrutura e do compilador, e deve ser tratado com a mesma seriedade que os dois últimos.
As condições em si devem ser consistentes no código para facilitar a leitura, por exemplo, GIVEN-WHEN-THEN-DEVE, etc.
Quarto, as
especificações devem ser simplificadas . É útil escrevê-los em ordem inversa:
Erros primeiro, nulos primeiro, caminho feliz por último. Então não há desejo de concluir o teste após um caso de usuário válido. Para componentes da interface do usuário: renderização, eventos. Para componentes com estado, todos os estados são consistentes.
Assim, a estrutura de uma boa especificação legível se parece com isso: 5 a 10 errados, um script válido (ou várias variações de um script)
É uma boa prática ao escrever uma especificação para escrevê-la na íntegra na forma de texto, e depois entregá-la a um colega para ler para obter clareza e falta de condições. Na verdade, você já pode começar a escrever a implementação. Muitas vezes, nesta forma, a tarefa é alienada, ou seja, bem, quando alguém escreve a implementação do teste.
Em quinto lugar, a
implementação do teste deve corresponder ao que está escrito na descrição .
É uma boa prática dividir-se em organizar-agir-afirmar para encontrar facilmente uma correspondência para uma ou outra parte da implementação. O texto das asserções e exceções, se presente, também deve ser correlacionado com as descrições dos testes, como regra, podemos simplesmente duplicá-las.
Desnecessário dizer que, ao adicionar condições ou asserções ao teste, você também precisa atualizar as descrições do teste.
Portanto, a sequência de redação da especificação pode ser a seguinte.
- leia a história do usuário
- componente de nome e script válido
- formular condições para um cenário válido
- complementar a especificação com scripts errados, colocando-os no topo
- deixe o vizinho ler e corrigir os desaparecidos
- implementar testes e componentes um por um usando um loop de refator vermelho-verde.