1.
Equipe ComunIP<br />Como Produzir código bem desenhado, bem testado e bem produzido em passos pequenos e verificáveis<br />DesenvolvimentoOrientado a Testes<br />

2.
Todos já ouviram a frase: ‘O que os compiladores deveriam fazer é realizar aquilo que eu quero que não aquilo que eu digo’.<br />A Programação Ideal<br />

3.
Programar é trabalhoso.<br />Requer correção e consistência durante meses e anos de esforço. <br />No melhor caso, um erro leva a um código que não compila.<br />No pior caso, leva a um BUG que aguardará o momento em que causará maior dano para acontecer.<br />Os seres humanos não são perfeitos. Não é nenhuma surpresa que os softwares contenham BUGs.<br />A Programação Realista<br />

4.
Não seria maravilhoso se houvesse uma ferramenta que alertasse você sobre erros de programação momentos depois de cometê-los – uma ferramenta tão poderosa que pudesse virtualmente eliminar a necessidade de depuração?<br />Infelizmente não existe tal ferramenta, mas existe uma técnica que oferece resultados semelhantes.<br />A Ferramenta Ideal<br />

5.
TDD (Test-DrivenDevelopment) é um rápido ciclo de teste, codificação e refinamentos.<br />Ao adicionar uma nova funcionalidade, um programador pode realizar dúzias desse ciclo, implementando e refinando o software em passos minúsculos até que não reste mais nada para ser acrescentado nem nada que deva ser removido.<br />Quando usado adequadamente, ajuda a melhorar a modelagem, documenta suas interfaces públicas e previne contra futuros erros.<br />TDD – O Que É?<br />

6.
Na época dos cartões furados, o programadores cuidadosamente verificavam à mão seus códigos para terem certeza de que iriam compilar. Um erro de compilação poderia desperdiçar demoradas sessões de execução e levar a intensas sessões de depuração.<br />Compilar deixou de ser um problema tão grande. A maioria dos IDEs verificam a sintaxe à medida que você escreve, e os compiladores melhoraram consideravelmente seu nível de verificação de sintaxe. O ciclo de escrever e compilar se tornou tão curto que os erros são fáceis de encontrar e de corrigir.<br />Por que funciona?<br />

7.
O TDD aplica o mesmo princípio para a semântica do programador.<br />Em pequenos intervalos de tempo, o TDD verifica se o código realmente faz aquilo que você pensa que ele deveria fazer.<br />Por que funciona?<br />

8.
Você comunica suas intenções duas vezes, colocando a mesma idéia de formas diferentes: uma com um teste, depois com o código de produção.<br />Quando os dois batem, é provável que foram codificados corretamente. Caso contrário, existe um erro de modelagem em algum lugar.<br />Os testes são escritos do ponto de vista da interface pública da classe. Ele foca no comportamento da classe, e não em sua implementação, ou seja, a atenção fica em criar interfaces que são ‘mais fáceis de usar’ no lugar de ‘mais fáceis de implementar’.<br />Princípios Básicos<br />

9.
Passo 1: Pense<br />Imagine que funcionalidade você quer para seu código, então pense em um pequeno incremento.<br />Depois, pense em um teste que falhe a menos que aquela funcionalidade esteja presente.<br />Como usar o TDD<br />

10.
Passo 2: Bandeira Vermelha<br />Escreva o teste. Escreva apenas o suficiente para o incremento atual de funcionalidade.<br />Respeite o encapsulamento. Codifique em termos do uso da interface e não como você imagina implementar internamente.<br />Nos primeiros testes, isso significa que você escreverá seu teste para usar métodos e nomes de classes que não existem ainda.<br />Depois que o teste for codificado, compile e deixe-o falhar.<br />Se o teste não falhar, ou não falhar da forma que você espera, alguma coisa está errada. Talvez o seu teste esteja quebrado, ou não testa aquilo que você imaginava. Corrija o problema, você sempre será capaz de predizer o que está acontecendo com o código.<br />Como usar o TDD<br />

11.
Passo 3: Bandeira Verde<br />Escreva somente o suficiente para que o seu teste funcione.<br />Não se preocupe com pureza nem elegância – simplesmente faça aquilo que é necessário para fazer o teste passar. Algumas vezes você poderá colocar a resposta ‘hardcoded’. Não se preocupe, pois você estará refinando o código em pouco tempo.<br />Execute o teste e veja-o funcionar.<br />Se o teste falhar, você pode voltar ao código anterior. Se não encontrar o problema, avalie apagá-lo e tentar de novo.<br />Como usar o TDD<br />

12.
Passo 4: Refine<br />Com todos os testes funcionando, você pode agora refinar seu código sem preocupação.<br />Revise o código e procure por possíveis melhoramentos.<br />Para cada problema que você encontrar, refine o código para corrigí-lo.<br />Refine quantas vezes você achar necessário. Faça o melhor código que puder, mas limite-se às funcionalidades existentes. Não antecipe necessidades futuras.<br />Lembre-se: refinamentos não podem alterar a funcionalidade atual. Novas funcionalidades requerem um novo teste.<br />Como usar o TDD<br />

13.
Passo 5: Repita<br />Quando estiver pronto para inserir uma nova funcionalidade, comece o ciclo novamente.<br />A cada vez que finalizar um ciclo do TDD, você acrescenta um pequeno pedaço de código bem testado e bem modelado.<br />Não se esqueça: “Teste tudo que possa quebrar.”<br />Como usar o TDD<br />

14.
Para usar o TDD, você precisa de um framework de testes.<br />Se sua plataforma não tem uma ferramenta xUnit, você pode fazer a sua própria. Algumas ferramentas possuem interfaces gráficas e outras ‘firulas’, mas nada disso é necessário. Tudo o que você precisa é de uma maneira de executar de forma integrada todos os seus testes, alguns métodos de asserção e um resultado de ‘sucesso’ ou ‘falha’.<br />Velocidade importa. Faça seus testes executarem o mais rápido possível, de preferência em menos de 10 segundos.<br />O CMake pode funcionar como um suite de testes.<br />Ferramentas<br />

15.
Testes de Unidade focam uma classe ou método por vez. Eles executam inteiramente na memória, o que os tornam muito rápidos.<br />“Testes de unidade executam rápido. Se não executam rápido, eles não são unidades de teste.”<br />Um teste não é de unidade se:<br />Conversa com um banco de dados<br />Comunica via rede<br />Modifica o sistema de arquivos<br />Você precisa preparar o ambiente antes de executá-lo<br />Testes que fazem isso são considerados de integração.<br />Testes de Unidade<br />

16.
Testes de Unidade não são suficientes.<br />Em algum ponto, seu código precisa comunicar com o mundo externo.<br />É possível usar TDD para esse código também.<br />O melhor a se fazer nesse caso é centrar o foco em apenas uma interação com o mundo externo por vez.<br />Seu teste de integração deve executar sozinho. Ele deve preparar o ambiente e após restaurar o ambiente anterior.<br />O número de testes de integração deve ser proporcional aos tipos de interação externa que seu programa possui, e não ao tamanho do código.<br />Se precisar de muitos testes de integração, isso é sinal de problemas de modelagem.<br />Por exemplo, se todos os objetos conversam diretamente com o banco de dados, você precisará de muitos testes. Uma modelagem melhor seria delegar a comunicação com o banco de dados a uma única classe.<br />Testes de Integração<br />

17.
Os testes de ponta-a-ponta varrem grandes linhas de execução do programa, normalmente começando na interface gráfica, passando pela camada de negócios, alterando um banco de dados, e retornando. Testes de Aceitação e Funcionais são exemplos de testes de ponta-a-ponta.<br />Eles podem dar maior confiança ao código, mas:<br />São difíceis de criar porque requerem preparação e restauração trabalhosas e suscetíveis a erro.<br />São obscuros e tendem a quebrar sempre que qualquer parte do sistema muda.<br />São extremamente lentos. Duram preciosos segundos ou minutos.<br />Provêem um falso senso de segurança, executando uma gama tão ampla de código, que fica difícil dizer exatamente quais partes estão sendo cobertas.<br />Testes de Ponta-a-Ponta<br />

18.
Definições:<br />“código sem testes”<br />“código o qual você tem medo de alterar”<br />“big ballofmud” ou “spaghetti software”<br />O desafio é que tais códigos não foram escritos para serem testados e pode ser que você tenha grande dificuldade de entender como tudo se encaixa.<br />Uma maneira de se trabalhar é realizar testes de fumaça(“onde há fumaça, há fogo”): você implementa testes com os usos que você conhece envolvendo o componente que você quer testar. Eles não serão suficientes para lhe dar total confiança nas suas alterações, mas pelo menos vai emitir um alerta sobre grandes erros.<br />Código Legado<br />