O documento discute princípios e práticas de desenvolvimento de software, enfatizando a importância de testes, código limpo e refatoração. Aconselha a adicionar testes rapidamente, executá-los com frequência e refatorar para remover duplicações.

4. Codificamos
Erramos
Depuramos

6.  Não existe refactoring, apenas rework.
 Se tiver funcionando, não rela a mão.
 Teste é para os fracos.
 Quanto mais XGH você faz, mais precisará fazer.
 Existem 3 formas de se resolver um problema, a
correta, a errada e a XGH, que é igual à errada,
só que mais rápida.
 Seja autêntico, XGH não respeita padrões.
Escreva o código como você bem entender, se
resolver o problema, commit e era isso.

7. Usuáriofinal
Controlede qualidade
Desenvolvimento
Implantação

11. Assegurar
qualidade.
Manter código limpo,
simples e testável.
Prover documentação para membros
técnicos.
Repetir testes - Regressão Preparados para mudar rapidamente.

12. Adicionar um teste
rapidamente
Rodar todos os
testes e ver o
mais nova
falhando
Fazer uma
pequena
mudança
Rodar todos os
testes e ver
todos
funcionando
Refatorar para
remover
duplicações
SucessoErro

14. Não sei como testar
Vai demorar muito
mais.
Isso não dá para
testar
A funcionalidade é
muito fácil.
Melhor deixar
testes com os
testadores

17. ATDD é o ato de se definir testes de
aceitação colaborativa no reflexão de
requisitos de negócio, resultando numa
melhor compreensão dos objetivos de
uma estória.
Os testes em ATDD nos forçam a
chegar a um ponto de acordo concreto
sobre o exato comportamento que se
espera que o software deva ter.

18. • Criar uma conta com uma senha
• Efetuar o login com um nome de usuário válido e
senha
• O que deve acontecer se um usuário informar uma senha insegura?
• Você pode nos dar exemplos de senhas que você considera seguras e inseguras?
• Quais são exatamente os símbolos?
• E quanto a espaços?
• E o que fazer com relação a palavras de dicionário com substituições óbvias que atendam
• aos critérios mais ainda possam ser inseguras, como 'p@ssw0rd'?”
• E quanto a contas já existentes?
• Quando você vai considerar que esta funcionalidade está 'funcionando'?
• O que deve acontecer se um usuário informar uma senha insegura?
• Você pode nos dar exemplos de senhas que você considera seguras e inseguras?
• Quais são exatamente os símbolos?
• E quanto a espaços?
• E o que fazer com relação a palavras de dicionário com substituições óbvias que atendam
• aos critérios mais ainda possam ser inseguras, como 'p@ssw0rd'?”
• E quanto a contas já existentes?
• Quando você vai considerar que esta funcionalidade está 'funcionando'?
test_valid_returns_true_when_all_conventions_met
test_valid_returns_false_when_password_less_than_6_chars
test_valid_returns_false_when_password_missing_symbol
test_valid_returns_false_when_password_missing_letter
test_valid_returns_false_when_password_missing_number

22. Itens devolvidos devem retornar para o estoque
que um cliente compra um jumper preto
eu tenho três jumper pretos no estoque
ele retorna com o jumper preto para reembolso
eu devo ter quatro jumpers pretos no estoque
Itens substituídos devem ser retornados ao estoque
que uma cliente compra um vestido azul
eu tenho dois vestidos azuis no estoque
eu tenho três vestidos pretos no estoque
ela retorna com o vestido para uma troca por um preto
eu devo ter três vestidos azuis no estoque
dois vestidos pretos no estoque

26. Fake são objetos extremamente leves e performáticos, construídos para simular
uma funcionalidade de um componente que o depende, ao invés do
real.
Devemos utilizar objetos Fakes sempre que depende de outros
componentes:
1. Que não estão disponíveis;
2. São difíceis de serem testadas (por exemplo post em páginas web);
3. Resultam em maior lentidão na execução dos testes;
4. Maior complexidade no comportamento do método que vale a pena um
Test Stub ou Mock object.

31. Objetos Mock são criados para testar o comportamento de algum outro objeto
(real). Portanto, mocking é fingir completamente o objeto real e fazer algumas
operações de uma forma controlada para que o (teste) resultado como válido.
Mock é uma maneira poderosa de implementar verificação de comportamento
evitando a duplicação de código de teste entre os testes semelhantes,
delegando a tarefa de verificar as saídas do em Test Double.

32. Devemos utilizar objetos Mocks quando:
1. O objeto fornece resultados não-determinísticos (por exemplo, o tempo
atual ou a temperatura atual);
2. Possuem estados que não são fáceis de criar ou reproduzir (por exemplo,
um erro de rede);
3. É lento (por exemplo, uma base de dados completa, que tem de ser
inicializado antes do ensaio);
4. Ainda não existe ou pode mudar o comportamento;
5. Necessidade de incluir informações e métodos exclusivos para fins de teste e
não para a sua tarefa real.

36. Providenciam respostas pré-configuradas para as chamadas feitas
durante os testes, normalmente não respondem a nada que não esteja
programado para o teste.
Stubs também podem gravar informações sobre as chamadas, como um
gateway que lembra as mensagens que 'enviou', ou talvez apenas
quantas mensagens 'enviou'.

40. Mesmo teste de Stub para Mock.

41. Stubs providenciam respostas pré-
configuradas para as chamadas feitas
durante os testes, normalmente não
respondem a nada que não esteja
programado para o teste. Também podem
gravar informações sobre as chamadas,
estado das informações.
Mocks são objetos pré-programados com
informações que formam uma especificação
das chamadas que esperam receber.

44. Padrão Propósito Tem
Comportamento
Injeta entrada
indiretas no SUT
Manipula saídas
indiretas do SUT
Valores fornecidos
pelo testador
Exemplos
Dummy Object
Atributo ou
parâmetro do
método
Não
Não, nunca
chamado
Não, nunca
chamado
Não
Null, "Ignored
String", new
Object()
Test Stub
Verify indirect
inputs of SUT
Sim Sim Ignorá-los Inputs
Test Spy
Verify indirect
outputs of SUT
Sim Opicional
Captura-los para
verificação
posterior
Inputs (opicional)
Mock Object
Verifique saídas
indiretas do SUT
Sim optional
verifica a exatidão
de encontro às
expectativas
Inputs e outputs
(opcional)
Fake Object
Executar
(unrunnable)
testes (mais
rápido)
Sim Não Usa-los Nenhum
Emulador de
banco de dados
em memória
Temporary Test
Stub
Stand in for
procedural code
not yet written
Sim Nao Usa-los Nenhum
Emulador de
banco de dados
em memória

47. Invertion of
Control (IoC)
Service
Locator
Events Delegates
Template
Methods
Pattern
Dependency
Injection
Construtor
Injection
Property
Injection
Method
Injection