Você realmente precisa fazer o BDD / TDD em uma primeira maneira de teste?

11

Embora eu não tenha participado de um projeto de TDD ou BDD, ou de alguns que dizem que estão fazendo TDD, mas estão muito longe disso, essas são coisas em que penso e realmente tento ler o máximo que posso sobre.

De volta à pergunta. Ao fazer o BDD, você deve escrever seu "teste" primeiro e fazê-lo falhar, certo? E então implemente esse recurso ou como você o chama. Mas se você levar isso ao extremo, isso não poderia ser algum tipo de desenvolvimento de cima para baixo? Você está olhando sua interface do usuário e diz: "Gostaria de ter esse recurso / comportamento aqui". Em seguida, você corrige sua interface do usuário para implementar esse recurso e o código que suporta a interface do usuário. Neste ponto, você não implementou nenhuma lógica comercial ou lógica de acesso a dados, apenas implementou seu comportamento. O que eu pretendo, em vez de escrever o teste, primeiro você escreve seu código de interface do usuário. Em alguns casos, deve resultar no mesmo código para a camada de negócios e acesso a dados, pois você usa o código da interface do usuário para definir o que sua empresa precisa oferecer suporte.

É claro que você deve complementar isso com testes que são usados para garantir que o recurso esteja funcionando como deveria.

Alguma ideia?

unit-testing tdd

— Tomas Jansson
fonte

Os testes no TDD são testes de unidade , que acionam o módulo diretamente, como se fosse através de um separado main. No seu comentário de cima para baixo, você está falando sobre testes funcionais, que executam todo o programa em um único main.

— Macneil

@ Macneil: Eu não falo sobre testes funcionais que testam todo o programa, mesmo que você esteja implementando / projetando seu programa de cima para baixo, você ainda deve implementar o teste de unidade para todo o seu código público. Só porque você faz isso de cima para baixo, não significa que você não pode abstrair diferentes camadas para poder isolar todas as camadas por si só.

— Tomas Jansson

1

@ Macneil: Este é um equívoco comum. Testes TDD não são testes de unidade . O TDD testa recursos que não possuem escala definida.

— Steven A. Lowe

2

Mas há uma escala definida: o teste deve ser executado rapidamente no TDD. Existem testes que devem ocorrer que também estão fora do escopo do TDD. No geral, o TDD é um plano de desenvolvimento, não um plano de teste.

— Macneil 31/05

@ Macneil: "rapidamente" é um termo relativo. O conjunto de testes no meu último projeto é executado em cerca de 30 minutos. Ele substitui 8 horas de teste manual. Isso é "rápido" o suficiente!

— Steven A. Lowe

8

Você está falando sobre o BDD de uma perspectiva de alto nível para testar sua interface do usuário. O teste é um pouco mais fácil nesse nível do que no código Javascript / servidor.

Vários livros que li no TDD dizem que você deve escrever código como se os sistemas subjacentes existissem e apenas escrever o suficiente para fazer o teste passar. Você pode escrever stubs no servidor para obter aprovação nos testes comportamentais da interface do usuário. Então você começa nesse stub seam e escreve alguns testes de unidade para o código do lado do servidor e trabalha até a implementação completa.

Costumo codificar como se as camadas subjacentes existissem para que um teste de alto nível passasse, é como descer por uma toca de coelho e extrair muitas outras classes para satisfazer o teste de alto nível e depois escrever testes para esses níveis mais baixos. Como você já reconheceu, ajuda a manter o foco, começando com testes de nível superior.

Como qualquer programador experiente sabe, há muitas camadas no desenvolvimento de software. Costumo trabalhar abaixo da interface do usuário e pensar nos dados ou no comportamento que minha interface precisa do servidor e começar por aí (talvez porque eu não faça muito trabalho na interface hoje em dia).

Se eu for realmente honesto, extrair uma classe das camadas subjacentes significa que não estou fazendo o teste primeiro, mas ... dentro de minutos ou às vezes horas, terei um teste para esse código. Isso ainda me parece benéfico, pois ajuda a ver onde você pode precisar fornecer dependências para uma classe e respeitar o princípio de responsabilidade única - se for difícil de testar, você está fazendo muito em um só lugar etc.

— Greg K
fonte

Eu acho que você está certo. Isso me ocorreu quando experimentei o ruby on rails neste verão, lá eles têm algum teste de bdd que aciona a interface do usuário que posteriormente impulsiona a implementação das classes subjacentes.

— Tomas Jansson

17

Sim! Caso contrário, o que você obtém é um teste orientado ao desenvolvimento .

Realisticamente falando, no entanto, existem problemas que são difíceis de abordar usando TDD "puro". Você pode ser mais produtivo escrevendo escrevendo um código de produção descoberto antecipadamente e cobrindo-o com testes mais tarde (e aprendendo a abordar problemas semelhantes com o TDD no futuro). Veja essa técnica , que seu autor chamou de TDD de enxágue e repetição por falta de um termo melhor.

— azheglov
fonte

3

Primeira linha é incrível.

— EpsilonVector

Comparado com o TDD, isso é verdade, mas fazer as coisas de cima para baixo deve se alinhar muito bem com o BDD, certo? Eu olho para a GUI e especifique o comportamento que desejo, com certeza não escreverei o "teste de comportamento" imediatamente, mas especifiquei o comportamento na interface do usuário antes de implementá-lo.

— Tomas Jansson

15

Se você não escrever seus testes primeiro, não estará conduzindo o desenvolvimento através dos testes. Portanto, você não está fazendo desenvolvimento orientado a testes!

— Frank Shearar
fonte

Para ser justo, não é mais a questão de saber se, ao fazer BDD (não TDD), devemos escrever o teste primeiro?

— Bydev

Sinta-se à vontade para substituir "teste" por "comportamento". Não vi nada para me convencer de que, no fundo, há muita diferença entre TDD e BDD. Foco, talvez. Mas a ideia central? Não muito.

— Frank Shearar

Não concorde com o fato de você não estar fazendo um desenvolvimento orientado a testes. Você não está fazendo isso de acordo com a definição do termo com chave, mas enquanto você estiver desenvolvendo testes para o seu código, seu código será definitivamente orientado pelos testes, independentemente de quando você os escrever.

— alternativa

TDD significa especificamente escrever testes antes do código. Se você não gosta disso, fale com Kent Beck, que inventou o termo. Escrever testes após o código pode conduzi-lo até certo ponto, mas você ainda pode se convencer de que está conduzindo seu design de código através de testes quando não está. E é mais difícil escrever esses testes, porque muitas vezes você precisa alterar o código não testado . Visto muitas vezes para mencionar.

— 21814 Frank Shearar

@FrankShearar Eu reconheci que não é TDD de acordo com o que Kent Beck disse, mas sinceramente não me importo com o que uma pessoa aleatória disse. É perfeitamente possível conduzir o design do código através de testes sem antes escrevê-los.

— alternativa

4

Se você quiser trabalhar dessa maneira, vá em frente. Mas não é um desenvolvimento orientado a testes.

— Don Roby
fonte

3

O que você descreve parece muito com a abordagem de design antecipado. Infelizmente, o Front-Ahead Design é a facada satírica de Alex Papadimoulis nos métodos ágeis.

— user281377
fonte

Eu queria saber se você conhece algum artigo que revide o FAD, desmascarando sua facada satírica?

— CL22 13/08/2015

3

Pessoalmente, acredito que é fundamental pensar em testes durante a fase de design. É realmente ótimo ter uma implementação funcional, mas a única maneira de garantir um produto em funcionamento é se você o testou peça por peça. A maneira de cobrir isso é através de uma combinação de testes de unidade e uma equipe qualificada de controle de qualidade trabalhando em parceria.

Agora, como você instala esse dicipline em sua equipe é com você. O TDD é uma dessas estratégias - e uma que tem seu lugar, e existem muitas outras variações. No entanto, o TDD não é particularmente adequado para o desenvolvimento de layout da interface do usuário.

— Michael Shaw
fonte