# 99 Bottles - Cap. 2 -

### Gab
- Shameless Green
- generic code

### Johny

#### The Transformation Priority Premise

-- link: https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html

- Robert C. Martin (Uncle Bob) diz que refatoradores possuem contrapartidas chamadas de tranformadores. Uma refatoração é uma operação que muda a estrutura de um código sem mudar seu comportamento, enquanto que uma transformação é uma mudança em código de específico para genérico que faz testes de ciclo red/green/refactor passarem
- ao seguir a linha de TDD utilizando de Shameless Green, passando os primeiros testes com casos específicos, vamos transformando nosso código de específico para genérico (e não de estúpido para inteligente) - “As the tests get more specific, the code gets more generic.”
- lista de transformações:
- ({}–>nil) no code at all->code that employs nil
- (nil->constant)
- (constant->constant+) a simple constant to a more complex constant
- (constant->scalar) replacing a constant with a variable or an argument
- (statement->statements adding more unconditional statements.
- (unconditional->if) splitting the execution path
- (scalar->array)
- (array->container)
- (statement->recursion)
- (if->while)
- (expression->function) replacing an expression with a function or algorithm
- (variable->assignment) replacing the value of a variable.
- A Premissa da Prioridade de Transformação: transformações no topo da lista tem prioridade sobre tranformações mais abaixo. Ao fazer um teste passar, tentar usar tranformações mais simples; ao escrever um teste unitário, tentar fazer com que seja aplicada uma transformação mais simples
- O Problema do Impasse: uma sequência de testes te leva a necessidade de escrever código demais e quebrar o ciclo red/green/refactor e outra evita o impasse, a premissa é que ao escolher testes e implementações que exijam transformações mais altas na lista você alcança o segundo cenário. Quando uma implementação está exigindo uma transformação de baixa prioridade, volte atrás e procure por um teste mais simples de passar

- #### Observações adicionais:
- "[W]hen faced with a problem you do not understand, do any part of it you do understand, then look at it again." - The Moon is a Harsh Mistress
- katas são formas interessantes de treinar a forma de estruturar TDD, acesso a atalhos, lógica e velocidade de programar
- link de um kata resolvido de números primos: https://github.com/Cs4r/prime-factors-kata
- blogpost do word wrap kata: http://thecleancoder.blogspot.com/2010/10/craftsman-62-dark-path.html

#### 99 Bottles - Cap 2

- Don't overthink. Encontre um ponto de partida e comece dali, vá fazendo mudanças aos poucos.
- Quando seguindo TDD, você troca entre dois papéis: o de escrever testes, de olho no inteiro; e o de escrever código, onde você finge não saber nada além dos requerimentos especificados pelo teste em mãos
- Ao aplicar mudanças em código, avaliar:
- A mudança faz a compreensão do código mais difícil?
- Qual o custo futuro de não fazer nada agora? (se não subir o custo, atrasar mudanças)
- Regra Henrique Morato: um é pouco, dois uma advertência, jamais triplique
- Evitar duplicações caso elas mais atrapalhem do que ajudem, caso uma duplicação não apresente nada de diferente, evite-a
- A dinstinção entre intenção e implementação permite entender seu código primeiro em essência e então, se necessário, em detalhe
- O primeiro passo em direção a arte de testar é entender como escrever testes que confirmem o que seu código faz sem nenhum conhecimento de como seu código faz
- Testes mal escritos diminuem a efetividade do TDD, permitem "roubar" e escrever código ruim que passa no teste que não tem boa cobertura. Testes bons aceleram o desenvolvimento, testes ruins o contrário

### Igor
- DRY é importante, mas se aplicado muito cedo e com muito vigor, pode trazer mais malefícios do que benefícios.

- _black boxes_

- _fixtures_

- "Green Bar Patterns" are:
- Fake It ("Til You Make It")
- Obvious Implementation
- Triangulate

- "When the obvious implementation is evident, it makes sense to jump straight to it.[...] there’s no need to wear a hair shirt and repetitively inch through a series of tiny steps."

- "Although it sometimes makes sense to skip the small steps and jump immediately to the final solution, exercise caution. It’s best to save Obvious Implementation for very small leaps."

- "The code is easy to understand because there aren’t many levels of indirection."

2.9 - Revealing Intentions

- Intenção x Implementação

"The distinction between intention and implementation allows you to understand a computation first in essence and later, if necessary, in detail."

"Senders of the song message want all of the verses, and they oughtn’t be forced to trouble themselves with details about how this happens."

2.10 - Writing cost-effective tests

- TDD does not claim to be free, merely that its benefits outweigh its costs.

- TDD can prevent costly guesses, but only if you commit to writing code in small steps.

- "Good tests not only tell a story, but they lead, step by step, to a well-organized solution."

- The first step in learning the art of testing is to understand how to write tests that confirm what your code does without any knowledge of how your code does it.

- "This new test asserts that song produces the same result as running the code currently contained in verses ."

### Dalvi
- TDD em baby steps revelam a implementacao correta (se vc pula para uma implementacao que imagina ser a melhor, caso descubra estar errado depois vc perde a chance de encontrar a implementacao correta durante esses passos)
- intencao x implementacao (song x verses(99,0))
- Testes devem confirmar oq seu codigo faz sem saber como
- Testes nao sao o lugar para abstracoes e sim para CONCRECOES

### Bruno
- TDD;
- Setup, Execução, Expect;
- - Case: explicito X if: condicionais diferentes e não explicitas
- song x verses(starting, ending)
- - dependencia
- Testes não são lugares para abstrações
- - evitar dependencias;
- - evitar adicionar/copiar lógica aos testes;

Questões:
- Durante o TDD, como enxergar ou ter uma visão do projeto como um todo? (big picture);
- Durante o TDD, como fazer testes que dependem de bibliotecas ou API's? Por exemplo, testes que necessitam de mocks.

Conclusões:
- "A TDD não afirma ser livre, apenas que seus benefícios superam seus custos."
- Testes não são lugares para abstrações
- - evitar dependencias;
- - evitar adicionar/copiar lógica aos testes;

Ações:
- Evitar DRY e "lógica" nos testes. Prezar pela legibilidade.
- Criador-estudos sobre testes. Levar esse assunto de forma mais aprofundada numa discussão futura.