O documento explora a importância dos testes de software, destacando os tipos de testes, como testes unitários e de integração, além de práticas de automação e Continuous Integration. Ele descreve vantagens dos testes, como a manutenção facilitada e segurança durante a refatoração, além de boas práticas para garantir a eficácia dos testes. A apresentação também aborda testes funcionais, de aceitação e de estresse, enfatizando a necessidade de validar a aplicação em várias condições.

1. Testes: existe
vida antes do TDD
Diana Ungaro Arnos

2. Objetivos
● Entender o que são testes de software;
● Entender a importância dos testes unitários
no desenvolvimento de software;
● Proporcionar uma visão geral sobre vários
tipos de teste.

3. Agenda
● Testes: por que, o que são e tipos;
● Testes automatizados e Continuous Integration;
● Testes unitários e mocking;
● Testes funcionais e de aceitação;
● Testes de estresse.

4. Testes: por que, o que são e tipos

5. Testes: por que, o que são e tipos
● Garantir que a aplicação faça a coisa certa do jeito
certo (Uncle Bob)
● Procurar e encontrar bugs
● Evitam perda de dinheiro e comprometimento da
imagem da empresa
● Podem ser caixa branca ou caixa preta
Com verificação de código
O código não interessa

6. Testes: por que, o que são e tipos
Tipos
Unitário
Testam unidades
individuais de código, como
classes e métodos
Integração
Testam partes da aplicação
e sua integração com o
resto do sistema (teste de
componentes). Identifica
erros de interface entre
módulos.
Sistema
São testes tipo caixa preta
que analisam a aplicação
ponta-a-ponta,
baseados nos requisitos de
sistema. Seguem roteiros,
definidos de acordo com
planos de teste pré
definidosCaixa branca

7. Testes automatizados e CI
Automatização de testes
● Utilização de software especializado que controla a execução de
testes e a comparação de resultados previstos e esperados;
Continuous Integration
● Prática de engenharia de software em que mudanças no código são
imediatamente testadas e reportadas quando adicionadas a uma
base de código (quando é feito um pull request)

8. Testes automatizados e CI
O cenário ideal
1. Pull request feito
2. Execução automática dos testes
disponíveis
3. É gerado um relatório com o
resultado dos testes e a
indicação se as alterações
podem ser integradas ao código
sem problemas

9. Testes automatizados e CI
O cenário OMFG! *_*
Todos os passos anteriores e mais:
4. Após a execução com sucesso
dos testes, o código é
automaticamente integrado
(merge)
5. O relatório gerado indica todas
as alterações que foram
adicionadas ao código (diff)
Obs.: O teste de sistema sempre terá uma parte
manual, mas também pode (e deve) ser
complementado com testes automatizados que cobrem
vários cenários

10. Testes automatizados e CI
Boas práticas de Continuous Integration
● Comitar código frequentemente;
● Categorizar os testes;
● Utilizar um servidor integrado de build;
● Utilizar mecanismos de feedback contínuo;
● Builds de staging.

11. Testes unitários e mocking
Objetivo: garantir o retorno esperado em todos os casos possíveis
O Caminho Feliz Fluxo Alternativo Fluxo de Exceção
Não testam lógica de negócio, apenas a
implementação do código

12. Testes unitários e mocking
Vantagens!
● Manutenção facilitada de código
● Segurança ao refatorar
● Serve como documentação
● Estimula melhor implementação
da programação orientada a
objetos
Sai mais barato descobrir um bug
em estágios iniciais de
desenvolvimento

13. Testes unitários e mocking
Seu teste está errado quando:
● Você precisa alterar seu ambiente para os testes rodarem sem problemas
(ex.: alterar configurações da aplicação)
● Faz comunicação com algum banco de dados
● Utiliza algum recurso de rede
● Utiliza seu sistema de arquivos

14. Testes unitários e mocking
Boas práticas!
● Cada teste verifica apenas um comportamento
● Um teste não deve depender do resultado de outro
● Testar apenas métodos públicos
● O nome de cada teste deve indicar o que está sendo testado e qual o resultado esperado (sim,
algunsNomesPodemFicarUmTantoGrandes)
● Usar testes parametrizados sempre que possível
Polêmica: usar um único método de assert por teste

15. Testes unitários e mocking
Mocking
Criação de objetos que simulam o comportamento de objetos reais e
substituem as dependências externas nos testes.
Stubs
Não têm lógica, apenas
retornam o que você
mandar, basicamente com
reusultados hard coded
Fakes
Mais próximos da
implementação de objetos
reais, possuem lógica e são
capazes de manter um
estado
Mocks
Objetos baseados em
expectativas e que simulam
comportamento, testam
interações entre objetos

16. Testes funcionais e de aceitação
Funcionais
São testes de verificação e
descrevem o que o sistema faz,
analisando as saídas de acordo com
as entradas, baseados nas
especificações de negócio. Por
exemplo: teste de cálculo de frete.
Aceitação
São testes de validação. Verificam se
a aplicação satisfaz as necessidades
do cliente. É a última camada de
testes, muitas vezes executada
quando a aplicação já está em
produção. Por exemplo: teste AB.
Testes Caixa Preta

17. Testes de estresse
Verificam robustez, disponibilidade e resiliência da
aplicação quando está sob condições desfavoráveis
● Não-funcionais;
● Caixa branca ou preta;
● De acordo com a definição pen testing e fuzz testing também pode ser
considerados testes de estresse.

18. DÚVIDAS?

19. Obrigada!
Diana Ungaro Arnos
Webdev @ Tricae
Twitter: @dianaarnos
G+: +DianaUngaroArnos
Facebook: /dianaaarnos