2. Separação de Conceitos
Testes manuais
Testes de Unidade
Testes de Integração
Testes de Aceitação
Testes de Carga
Testes de Stress
3. Anatomia de Teste (jUnit)
Um teste deve testar apenas uma pequena
funcionalidade
Deve ser claro o que o teste deve fazer
4. Exemplo:
Teste conciso?
Diz claramente o que
está sendo testado?
public class RotinaBackupTest {
public void setup() {....
}
public void tearDown() {.....
}
@Test
public void testBackup() {
...
}
}
6. Nomes são importantes
Lembre-se quando você bater o olho no
método do teste, você deve saber exatamente
o que está sendo testado.
7. Testes de integração
Testam a interação entre componentes do
sistema
Usado geralmente nas fronteiras do sistema:
Banco de dados
Acesso a Ldap
Leitura de arquivos
etc...
8. Testes de integração
Devem ser isolados também, pois o
comportamento deve ser repetitível.
São mais difíceis de ser escritos.
bibliotecas que ajudam:
DBUnit - permite mockar banco de dados
Unboundid - instancia um servidor de ldap
Jetty - pemite subir um container de servlet
Etc...
9. Outros tipos de testes
Testes de aceitação - testes desenvolvidos
para que o usuário final possa averiguar se o
sistema está tendo o comportamento
esperado, devido a fragilidade destes testes,
são raramente implementados.
Ferramentas:
Selenium, Phantomjs, Capybara, etc...
10. Outros tipos de testes
Testes de carga: testes que tem como
premissa gerar um carga no sistema simulando
o seu comportamento quando diversos
usuários estão usando o programa.
Ferramentas:
JMetter, apache AB, Selenium Grid, etc...
11. Outros tipos de testes
Testes de Stress: testes que tem como
premissa gerar um stresse no sistema para ver
como ele se comporta. Será que vai perder
dados? Será que o número do pool está bem
escalonado?
Ferramentas:
JMetter, apache AB, etc...
12. Piramide de testes
99% do código deve ser testado
60% deve ser testado
10% deve ser testado
Cobertura do teste
13. Problemas comuns nos testes
Os testes de unidade devem ser isolados:
● somente uma classe deve ser testada
● Dependências devem ser mockadas
14. Mockito
Biblioteca usada para fazer mocks de classes
Permite definir o comportamento das
dependencias
Simples de usar
15. Exemplo:
public class CadastroDeUsuarioActionTest {
@Mock
private GerenciadorUsuarios gerenciadorUsuarios;
@Mock
private MensagensTela mensagensTela;
private CadastroUsuarioAction cadastroUsuario;
@Before
public void setup(){
// use static imports para classes mockito
initMocks(this);
cadastroUsuario = new CadastroUsuarioAction();
cadastroUsuario.gerenciadorUsuarios = gerenciadorUsuarios;
cadastroUsuario.mensagensTela = mensagensTela;
}
16. Exemplo: Continuação
@Test
public void deveriaEmitirAlertaParaUsuarioParaErrosDeCadastramentoNoGerenciadorUsuarios(){
Usuario usuario = new Usuario();
doThrow(new CadastroInconsistenteException()).when(gerenciadorUsuarios).salvar(usuario);
cadastroUsuario.salvar(usuario);
verify(mensagensTela).adicionarMensagemErro("Cadastro inconsistente");
}
}
17. DSL para gravação comportamento
doReturn(usuario).when(cadastroUsuario).salvar(usuario);
doCallRealMethod().when(cadastroUsuario).salvar(usuario);
doAnswer(answer).when(cadastroUsuario).salvar(usuario);
doThrow(toBeThrown).when(cadastroUsuario).salvar(usuario);
reset(cadastroUsuario);
22. Finalmente:
Dicas finais:
Jcobertura - dedo duro do codigo não testado
SonarQube já tem jcobertura por padrão para
os projetos analisados.
Use TDD (tente pelo menos), o efeito colateral
é que já terá um teste implementado para cada
implementação de código que fizer.