Your SlideShare is downloading. ×
0
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Desenvolvimento Orientado A Testes
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Desenvolvimento Orientado A Testes

900

Published on

Como Produzir código bem desenhado, bem testado e bem produzido em passos pequenos e verificáveis

Como Produzir código bem desenhado, bem testado e bem produzido em passos pequenos e verificáveis

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
900
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 />

×