Final Project (2013): Test-Driven Development applied on web applications
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
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
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
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.