Introdução Flashcards
(35 cards)
Qual o problema que o BDD resolve?
Problemas de entrega de valor.
Softwares entregues sem as features requisitadas
Softwares com entrega atrasadas ou que são cancelados
Processo de desenvolvimento comum
- Aquele que têm a lógica de negócio fala para o analista de negócios o que ele quer
- O analista de negócios escreve um documento de requisitos
- O desenvolvedor transforma os requisitos em software
- O testador transfoma os requisos em casos de teste
5a. O produto finalizado é entregue ao cliente.
5b. O escritor técnico escreve a documentação
Processo de desenvolvimento proposto pelo BDD
- Aquele que têm a lógica de negócio e o analista de negócios discutem sobre o que o négocio precisa
- O analista de negócios, o desenvolvedor e testador escrevem os requisitos do software juntos. Eles estruturam os requisitos em uma linguagem natural e ubíqua
- O desenvolvedor transforma os requisitos em software
- O testador transfoma os requisos em casos de teste
5a. O produto finalizado é entregue ao cliente.
5b. O escritor técnico escreve a documentação
Processo de desenvolvimento proposto pelo BDD
- Aquele que têm a lógica de negócio e o analista de negócios discutem sobre o que o négocio precisa
- O analista de negócios, o desenvolvedor e testador escrevem os requisitos do software juntos. Eles estruturam os requisitos em cenários com uma linguagem natural e ubíqua
- O desenvolvedor transforma os cenários em software com a ajuda dos testes automatizados
- O testador usa os cenários como base para os testes
- Os testes automatiados provêem feedback do progresso e ajudam a documentar a aplicação
Qual as duas principais razões de falha de um processo de desenvolvimento?
Não construir o software direito
Não construir o software certo
O que é construir o software direito?
Se concentrar em como fazer o software
O que é construir o software certo?
É construir o software que atenda a necessidade do negócio
O que acontece se se concentrar somente em construir software direito?
Um software que não satisfaz o cliente
O que acontece se se concentrar somente em construir o software certo?
Um software difícil de manter e extender
O que é o BDD?
Um conjunto de prinpícios baseados em metodologias ágeis e de engenharia, principalmente DDD e TDD para processos de desenvolvimento.
Quem criou o BDD e por que?
Dan North como um jeito fácil de ensinar TDD
Quem criou o TDD e basicamente como funciona?
Kent Beck. Basicamente é criar um teste para uma feature, criar um código básico para que o teste passe, refatorar o código para conseguir um bom design.
Quais os problemas do TDD?
Desenvolvedores muitas vezes têm dificuldade em saber onde começar a testar ou o que testar em seguida.
As vezes TDD faz com o que o desenvolvedor fique focado em detalhes e esquecer a visão ampla do que o projeto precisa.
Grandes números de testes unitários acabam ficando difíceis de manter.
Os testes focam em funções e não em termos de negócio.
Como BDD melhora o TDD?
Ele foca no comportamento das classes e não em métodos.
Uma forma é por assinar o método de teste com ‘should’ e a descrição do que a classe deve fazer.
Como BDD melhora a análise de software?
Usando uma linguagem ubíqua e estruturada, o Gherkin
Outras nomes que significam o mesmo que o BDD
Acceptance-Test-Driven-Development(ATDD)
Accept-Test-Driven Planning
Specification By Example
workflow BDD
Comece por identificar os OBJETICOS DE NEGÓCIO.
OBJETIVOS DE NEGÓCIO são constituídos por FEATURES.
FEATURES são ilustradas por EXEMPLOS
ESPECIFICAÇÕES EXECUTAVEIS guiam o desenvolvimento e os testes
Como se subdivide as ESPECIFCAÇÕES EXECUTÁVEIS
Documentação viva: Ajuda testadores, analistas de negócios e usuários a saber o que está sendo feito.
Relatórios em tempo real: Quanto foi feito, quanto precisa ser feito
Documentação técnica: Faz o código fácil de manter e atualizar
Validação automática: Regressão automática e testes automáticas vêm como consequência
Features funcionais: O código em funcionamento
Princípios BDD
Foco em features que entregam valor
Especifique features em grupo
Abrace incertezas
Ilustre features com exemplos
Não escreva testes automatizados, escreva especificações executáveis
Não escreva testes unitários, escreva especificações de baixo nível
Entregue documentação viva
Use documentação viva para apoiar trabalho de manutenção em progresso
O que envolve o princípio:
Foco em features que entregam valor
Feature é uma peça de funcionalidae que ajuda o negócio a atingir o seu objetivo.
Ao invés de levantar todos os requisitos de uma vez, conversar com stakeholders e usuários finais pogressivamente que funcionalidade precisam.
Ao invés de receber uma lista de funcionalidades do cliente e não questionar nada, procurar entender o real motivo de negócio e sugerir funcionalidades que sejam realmente úteis.
O que envolve o princípio:
Especifique features em grupo
Testadores e desenvolvedores têm a oportunidade de fornecer seu know-how, além de ficarem mais engajados e responsáveis pelo produto.
O que envolve o princípio:
Abrace incertezas
As especificações do que deve ser desenvolvido nunca são entendidas no início, por isso entregue features com valor o quanto antes para receber o feedback ao invés de esperar ficar tudo pronto para saber se era realmente ncessário
O que envolve o princípio:
Ilustre fatures com exemplo
Quebre as features em User Stories com Gherkin.
Crie exemplos para casos perfeitos e casos alternativos
O que envolve o princípio:
Não escreva testes automatizados, escreva especificações executáveis
Ao escrever features você pode utilizar ferramentas que permiter executar essas especificações e gerar a documentação, deixando o processo de verificação ágil.
