Se você está familiarizado com TDD então ATDD é de alguma forma TDD com um nível mais alto de testes e com mais participantes envolvidos, em outras palavras, é mais um teste de aceitação do que um teste unitário. Se você quer saber mais sobre TDD então por favor verifique o seguinte post:
Acceptance test-driven development (ATDD) é uma metodologia de desenvolvimento baseada na comunicação entre os clientes empresariais, os desenvolvedores, e os testadores. ATDD engloba muitas das mesmas práticas de especificação por exemplo, desenvolvimento baseado em comportamento (BDD), desenvolvimento baseado em exemplo (EDD), e desenvolvimento baseado em suporte também chamado desenvolvimento baseado em teste de história (SDD). Todos esses processos ajudam os desenvolvedores e testadores a entender as necessidades do cliente antes da implementação e permitem que os clientes sejam capazes de conversar em sua própria linguagem de domínio.
Largamente implementado dentro das equipes Agile, o ATDD é uma prática onde analistas de negócios, desenvolvedores, testadores e os usuários trabalham juntos para definir cada critério de aceitação de story (ou recurso) em uma fase inicial do processo de desenvolvimento (antes do início da codificação). Esta abordagem permite que todos os interessados tenham e mantenham o mesmo nível de resultados esperados antes de qualquer desenvolvedor iniciar a codificação.
Eu sei que todos nós ouvimos este estereótipo de “Os desenvolvedores não se importam com a especificação e os testadores não querem fazer automação” mas com ATDD isso vai economizar muito tempo e dinheiro, garantindo que os desenvolvedores estejam mais envolvidos nos estágios iniciais da especificação e que o testador esteja automatizando os testes de aceitação.
Como ATDD é implementado na “vida real”?
Você está usando SCRUM? Se sim, então você já está fazendo a maior parte do trabalho no ATDD. Se não, então o seguinte exemplo deve alimentar sua curiosidade :
Exemplo
Vamos assumir que o proprietário do produto ou o cliente solicitou o seguinte recurso em nossa aplicação móvel: “Como usuário eu quero ignorar a tela de login para que eu possa usar a aplicação anonimamente” Depois de rever este pedido com toda a equipe (analista de negócios, desenvolvedores, testadores…) e com mais detalhes adicionados à história ou à funcionalidade, teremos alguns testes de “aceitação” ou “funcionais” semelhantes a este (Por favor note que este é apenas um exemplo, muitos testes de aceitação estão faltando para esta funcionalidade):
- Critério de aceitação 1: A aplicação aceita opcionalmente login/password para login
- Critério de aceitação 2: O bypass do botão permite que o utilizador navegue dentro da aplicação sem login.
- Critério de aceitação 3: Quando o botão ignorar selecionado, a aplicação não armazena ou exibe nenhuma informação específica do usuário.
- Critério de aceitação 4: Quando o login/senha são usados, a GUI da aplicação deve ser ajustada às configurações do usuário.
Benefícios
1- Alinhamento Cliente-Vendedor : Tendo os critérios de aceitação acima como informação de entrada, nós (cada membro da equipa) temos agora a certeza que a aplicação irá manter a sua funcionalidade de login/password e irá apenas adicionar um botão para permitir ao utilizador contornar a tela de login.
2- Qualidade e custo-benefício: Os testes acima podem ser facilmente automatizados mesmo antes dos desenvolvedores começarem a codificar.
3- Time to Market: Uma vez implementados os testes, os desenvolvedores podem validar suas tarefas requeridas antes de anunciar que terminaram.
ATDD não requer nenhuma ferramenta específica. É importante saber, que NÃO todos os testes de aceitação devem ser automatizados. Automatizar seus testes depende de múltiplos aspectos como: desafios técnicos, prazo e custo.
Ainda ferramentas recomendadas?
ATDD não requer nenhuma ferramenta específica. É importante saber, que NÃO todos os testes de aceitação devem ser automatizados. Automatizar seus testes depende de múltiplos aspectos como: desafios técnicos, prazo e custo.
Nesta seção eu lhe darei apenas uma visão geral das ferramentas de automação mais utilizadas no ATDD:
FitNess: O wiki standalone totalmente integrado e framework de testes de aceitação
Robot framework: framework genérico de automação de testes para testes de aceitação e desenvolvimento orientado a testes de aceitação (ATDD)
Calabash: Teste de aceitação automatizado para aplicativos móveis – Esteja ciente de que este framework pode não suportar a versão mais recente do SO (acima do Android O )