O documento discute o desenvolvimento orientado a testes (TDD) aplicado a sistemas web. Ele explica o que é TDD e testes de unidade, os benefícios do TDD, os ciclos de desenvolvimento no TDD, métricas para medir a qualidade do código com TDD e ferramentas como NUnit e QUnit para realizar testes automatizados em sistemas web.

1. Desenvolvimento orientado a testes
aplicado a sistemas web
FATEC - Análise e Desenvolvimento de Sistemas
Autor: Luiz Henrique Monteiro Assunção
Orientador: Norton Glaser

2. Agenda
 Motivação da Pesquisa
 Referencial teórico
 O que é TDD e Teste de Unidade?
 Benefícios e efeitos
 Ciclos de desenvolvimento
 Métricas
 Ferramentas utilizadas no mercado
 NUnit
 QUnit
 Entrevista
 Considerações Finais

3. Contexto
Fonte: http://sembugs.blogspot.com.br/2013/02/tdd-test-driven-development.html

4. Contexto
Fonte: http://sembugs.blogspot.com.br/2013/02/tdd-test-driven-development.html
Abordagem Test after

5. Desenvolvimento orientado a testes
Test-Driven Development
TDD
 Criado por Kent Beck
 Alinhado com práticas ágeis, principalmente Extreme Programming (baby steps)
 Sugere ao programador que escreva o código de teste antes do código de
produção
 Não escrever uma linha de código sem que você tenha um teste automatizado
falhando (BECK, 2002)

6. Etapa 1: Adicionar um teste
 Teste de Unidade
 Uma porção de código escrita por um desenvolvedor que representa uma parte de
uma específica área do código de uma funcionalidade testada (HUNT, 2007)
 Cada nova funcionalidade é iniciada escrevendo um teste
 Deve ser escrito antes do código de produção
 Focar nos requisitos antes de codificar. Analisar o que está fazendo.

7. Etapa 2: Executar todos os testes
 Checar se existe alguma falha
 Valida se o sistema está funcionando corretamente
 O teste da Etapa 1 falhará
 Confiança de que as outras partes do software estejam funcionando

8. Etapa 3: Escrever algum código
 Objetivo: solucionar o problema da maneira mais minimalista possível
 Escrever comandos simples para fazer com que o teste passe
 Neste estágio, o código não precisa ser perfeito
 Resultado: eliminação de possíveis códigos que não serão utilizados

9. Etapa 4: Executar todos os testes
 Verificar se todos os requisitos estão coerentes
 Nenhum teste pode falhar
 Analisa se a adição do novo código “quebrou” alguma parte do sistema

10. Etapa 5: Refatorar o código
 Aumento na qualidade do código
 Melhorar a manutenção
 O desenvolvedor terá confiança para alterar o código. Os testes mostrarão se
ocorreu algum problema
 Utilizar técnicas
 Remoção de duplicação
 Renomear variáveis com nomes mais expressivos
 Mover código para local apropriado

11. Ciclo iterativo do TDD
Fonte: http://www.lucianotulio.com.br/wp-content/uploads/2013/03/tdd-642x435.png

12. Benefícios e efeitos
 Assegurar a qualidade do código desde o início
 Redução da quantidade de bugs recorrentes
 Desenvolvedores adquirem mais confiança para refatoração
 Documentação no código
 Software manutenível
 Fidelidade do código com os requisitos do negócio
 Alinhamento com os princípios SOLID
 Separação de responsabilidades
 Software aberto a modificações

13. Métricas
 Na engenharia de software, as métricas são importantes para realizar
avaliações no produto e tomar decisões
 Permite realizar uma análise quantitativa
 São apenas indicadores

14. Métrica: Cobertura de Código
 Mede o quanto o código está testado
 Número proporcional com a quantidade de código que possui ao menos um
teste de unidade que teste-o
 Um código que não esteja 100% coberto não necessariamente significa que a
qualidade do software esteja baixa
 Para um desenvolvimento utilizando TDD, acima de 85% de cobertura é um
número considerável

15. Métrica: Lines of Code (LoC)
 Mede o tamanho do software
 Número de LoC é proporcional ao esforço alocado para manter o software
funcionando
 TDD auxilia na redução por buscar soluções simples
 Não revela a complexidade dos algoritmos

16. Métrica: Complexidade Ciclomática
 Mede quão complexo é um algoritmo (método).
 Complexidade = número de caminhos que um método pode ter
 Cada condicional aumenta a complexidade
 Quanto maior a complexidade, maior o risco de ocorrer algum erro
Valor da Complexidade Risco
1-10 Baixo Risco
11-20 Risco Moderado
21-50 Alto Risco
> 50 Alto Risco (não é testável)
Impactos da complexidade ciclomática por método
Fonte: http://www.mccabe.com/pdf/MeasuringSoftwareComplexityUAV.pdf

17. Métricas
Tipo de Métrica O que ela mede
Cobertura de código O quanto o código está testado
Lines of Code (LoC) Tamanho do software
Complexidade Ciclomática Complexidade dos algoritmos
Fonte: Autoria própria

18. Frameworks para TDD em sistemas Web
 Muito esforço realizar os baby steps manualmente. Framework de testes
automatiza a execução da suíte
 xUnit: uma das primeiras iniciativas para se criar frameworks de testes de unidade
 Junit (Java)
 NUnit (C#)
 QUnit (Javascript)
 Ambiente:
 C# no Server-Side
 Javascript no Client-Side

19. NUnit X Visual Studio Unit Framework
NUnit VS Unit Framework
Software maduro e estável Lançado com o VS 2008
Open Source (gratuito) Desenvolvido pela Microsoft
Releases frequentes Atualização conforme VS
Velocidade na execução Possui IDE fácil de utilizar
Integração com outras ferramentas
open source
Integração com Team Foundation
Server

20. NUnit - Execução de testes

21. QUnit X Jasmine
QUnit Jasmine
Utilizado no projeto jQuery Utilizado em projetos Ruby
Foca no Javascript usado no browser Pode ser utilizado em projetos que não
possuam Javascript como linguagem
para comunicação com o DOM (Node.Js)
Simplicidade na utilização

22. QUnit - Execução de testes

23. Pesquisa sobre testes automatizados
 40 desenvolvedores entrevistados
 81% dos entrevistados realizam testes manualmente
 35% dos entrevistados possuíam plena confiança do funcionamento de toda a
aplicação, após modificações
 55% dos entrevistados afirmam que existe uma alta incidência de erros em
ambiente de produção na empresa onde trabalham
 8% dos entrevistados utilizam a abordagem TDD

24. Referências Bibliográficas
 BECK, K. Test-Driven Development by Example, 1ª ed. USA: Addison-Wesley
Professional, 2002.
 FOWLER, M. xUnit. Disponível em:
http://www.martinfowler.com/bliki/Xunit.html Data de Acesso: 20 de
novembro de 2013.
 HUNT A.; THOMAS D.; Pragmatric Unit Testing in C# with NUnit, 2ª ed.
Texas: The Pragmatric Programmers, 2007.

25. Obrigado pela atenção!