testes de software de a a z
Post on 14-Feb-2017
210 Views
Preview:
TRANSCRIPT
Teste de Software de A a ZPalestrante: Camilo Porto
https://www.linkedin.com/in/camiloporto
SumárioMotivação tradicional para Teste de Software
Testes sob outra óptica
Escrever teste antes ou depois de Codificar? Avaliando Impactos
Design X Testabilidade
Importância da automação e ferramentas
Motivação TradicionalPor que testar software?
Primeiramente, o que é um teste?Teste = <cenário, lógica a validar, verificações>
ExemploCenário: parcela1 = 6; parcela2 = 9
Lógica a validar: soma(parcela1, parcela2) : resultado
verificações: resultado == 15
Escrever um teste, portanto, consiste em:Definir o cenário;
Executar a lógica no contexto do cenário criado
Fazer verificações para validar o resultado obtido.
Pesquisa Rápida...
Quem acha que testar código é importante?
Quem acha difícil testar código?
Quem acha chato?
Quem escreve teste para o código que escreve?
Por que testar código de software?
Motivos tradicionaisGarantir que código escrito funciona como imaginado
Tentar identificar bugs em funcionalidades já escritas
Testes sob outra ópticaVisão mais abrangente da prática de teste de software
Já pensou em escrever teste para...Definir/Expressar onde se quer chegar (objetivo/escopo) com o
código que você irá começar a escrever?“Vou codificar um cadastro de usuário...”
Já pensou em expressar isso em Java? Com um teste?
Já pensou em escrever teste para...Definir como a nova funcionalidade será usada (Interface de Uso)?
“Minha classe de negócio vai receber um objeto Usuário com email, nome e rg e retornará um Relatório da Operação informando se o cadastro foi realizado com sucesso ou com uma lista de erros ocorridos”
Já pensou em expressar isso em linha de código?
Já pensou em escrever teste para...Dar foco ao trabalho de codificação...
“O cadastro de usuário deve:
● Validar entradas
● Inserir dados no banco de dados
● enviar email para o usuário ativar cadastro”
Por onde começar?
Já tentou expressar com um teste somente o “próximo passo”?
Já pensou em escrever teste para...Melhorar o design do seu código (acoplamento, coesão, ..)
Já pensou em escrever teste para...Documentar o Software?
O que vocês acham que a classe PaísRepository faz, olhando somente para a sua suíte de teste?
Consulta um País pelo número de habitantes?
Consulta um país pelo seu nome?
Como você acha que pode usar essa classe, olhando somente para um de seus testes?
O que ela espera receber?
O que você esperar obter de resultado?
public void deveConsultarPorNome() { String nome = “brasil” List<Pais> resultado = paisRepository.get(nome) …. …..}
Já pensou em escrever teste para...Debugar o Software?
Onde, nas 60KLOCs, está o bug?
Já pensou em escrever teste para...Melhorar manutenibilidade?
Você se sente mais seguro em manter um software com uma bateria robusta de testes?
Se você fizer bobagem, qual a chance de o teste te alertar?
E se não existir teste?
Já tentou fazer uma grande refatoração em software sem teste? (Atualizar uma biblioteca para uma nova versão? usar um novo componente?)
Já pensou em escrever teste para...Aumentar velocidade do desenvolvimento?
Parece contraditório??
Quanto tempo se leva para:Entregar nova função em produção
Em um software com 60.000 LoC
● Sem testes..
● Com testes?
“... isso estava funcionando.. mas agora, não sei por que, parou de funcionar.. e eu nem mexi aí…”
Encare testes também como uma ferramenta de Produtividade
Quando escrever o teste?Antes ou depois de a função já codificada?
Escrevendo o teste depois....
Depois de a função codificada...●Lógica já está definida;
●Interface de uso já definida
●Design (classes, métodos, acoplamentos, responsabilidades) já elaborado.
●Nesse contexto, qual é o papel do teste?○ Confirmar comportamento esperado
○ Cobrir cenários excepcionais.
Depois de a função codificada...Pontos de atenção
●O escopo da função foi definido em função do cliente (classe que irá invocá-la) ou o foco tende a ser o algoritmo?
●Pensou-se em deixar o código testável? Ou, somente no momento de escrever o teste, identificou-se uma dificuldade/inviabilidade de testar o código?
●O código já ta pronto… há realmente necessidade de escrever teste?
○ “Eu já vi que funciona”
Depois de a função codificada...Resumo
●Atenção e foco tende a recair no algoritmo, puro e simplesmente
●Análise de cenários possíveis (“what if”), que podem não se concretizar, e a definição sobre o que fazer tendem a ocorrer de forma caótica e simultânea
○ “E se for null? E se x < 13?”
○ NullPointerException? IllegalArgumentException? return -1?
○ Vai fazer sentido para o cliente da função?
●Tendência de ficar em segundo plano○ Interface de uso
○ Design (acoplamento coesão)
○ Testabilidade
E se escrevermos o teste antes?
Cadastro de Usuário...Receber informações de nome, email e senha do usuário;
Realizar validações e persistir informações
Sinalizar se sucesso ou erro
Enviar email com link para ativação da conta.
Expressando como um teste….class CadastroUsuarioTest {
} Vou fazer o Cadastro de Usuários
Expressando como um teste….class CadastroUsuarioTest {
deveInserirNovoUsuarioNoBanco() {
}
}
Vou começar fazendo a parte que insere os dados no banco…
Começando no cenário de inserir um novo usuário...
Expressando como um teste….class CadastroUsuarioTest {
CadastroUsuario cadastro = ...;
deveInserirNovoUsuarioNoBanco() { Usuario u = new Usuario() //u.set... com valores bem comportados..
Usuario salvo = cadastro.salvaUsuario(u)
assertNotNull(salvo.getId()) }}
Quem for usar essa função, vai me passar as informações dentro de um objeto Usuario…
.. e vai chamar o método salvaUsuario.
… vou retornar o mesmo objeto, com a informação do ID gerado pelo banco como sinal de que tudo deu certo.
Cenário após conclusão do raciocínio
class CadastroUsuarioTest {
CadastroUsuario cadastro = ...;
deveInserirNovoUsuarioNoBanco() { Usuario u = new Usuario() //u.set... com valores bem comportados..
Usuario salvo = cadastro.salvaUsuario(u)
assertNotNull(salvo.getId()) }}
código do teste código de produção
Fizemos alguma coisa?
Definimos Interface de Uso?nome: salvaUsuario
recebe: um único argumento cujo tipo é Usuario
retornase sucesso: mesmo objeto de entrada, com ID atribuído;
se falha: ???? (ainda não pensamos sobre isso… o foco ainda não chegou neste ponto).
exceções: ???
Definimos o foco/escopo/objetivo do trabalho?O que você vai fazer agora?
A.Um enviador de email que manda o link de ativação quando o usuário é cadastrado?
B.Validar se as informações do usuário são válidas?
C.Tratar o caso onde o argumento ‘Usuario’ for nulo?
D.Algum código que persita as informações do Usuário e gere uma identificação para ele.
Documentamos nosso código?No momento, o que deve fazer a classe CadastroUsuario?
A.deve remover usuários?
B.deve enviar emails de ativação?
C.deve inserir novo usuário?
D.deve lançar alguma exceção caso algo de errado ocorra?
Afetamos o design do código de produção?Quanto à testabilidade…
Fizemos um código de produção testável?
Nem mesmo escrevemos o código, mas seja ele qual for, não só vai nascer testável, como TESTADO!
Fazendo o teste passar...
Implementado a função
class CadastroUsuarioTest {
CadastroUsuario cadastro = ...;
deveInserirNovoUsuarioNoBanco() { Usuario u = new Usuario() //u.set... com valores bem comportados..
Usuario salvo = cadastro.salvaUsuario(u)
assertNotNull(salvo.getId()) }}
código do teste código de produção
class CadastroUsuario {
usuario salvaUsuario(Usuario u) { Long idGerado = bancoDeDados.insere(u); u.setId(idGerado); return u; }}
Cenário após a codificação
class CadastroUsuarioTest {
CadastroUsuario cadastro = ...;
deveInserirNovoUsuarioNoBanco() { Usuario u = new Usuario() //u.set... com valores bem comportados..
Usuario salvo = cadastro.salvaUsuario(u)
assertNotNull(salvo.getId()) }}
código do teste código de produção
class CadastroUsuario {
usuario salvaUsuario(Usuario u) { Long idGerado = bancoDeDados.insere(u); u.setId(idGerado); return u; }}
✓ Testável✓ Testado (cobertura de testes)✓ Justo (nada de “what-if”)✓ Refatoração segura
Escreva um teste antes de implementar lógica de produção
Design e TestabilidadeComo seu design (in)viabiliza testar seu código?
Design e TestabilidadeDesign do código impacta a testabilidade
Baixa testabilidade pode sinalizar pontos de atenção no design (code smell)
Analisemos alguns cenários...
new… Vs Injeção de Dependênciaclass CadastroUsuario {
BancoDeDados bancoDados;
usuario salvaUsuario(Usuario u) {
bancoDados = new BancoDeDadosOracleDaInfraEstrutura()
Long idGerado = bancoDeDados.insere(u); u.setId(idGerado); return u; }}
new… Vs Injeção de Dependênciaclass CadastroUsuarioTest {
CadastroUsuario cadastro = ...;
deveInserirNovoUsuarioNoBanco() { Usuario u = new Usuario() //u.set... com valores bem comportados..
Usuario salvo = cadastro.salvaUsuario(u)
assertNotNull(salvo.getId()) }}
● Em qual banco será inserido?● Como faço para, ao testar, usar
outro banco?● Consigo configurar facilmente
CadastroUsuario para um banco de testes?
new… Vs Injeção de DependênciaViabilizando o teste...
class CadastroUsuario {
BancoDeDados bancoDados //… recebe por Injeção de Dependência;
usuario salvaUsuario(Usuario u) {
bancoDados = new BancoDeDadosOracleDaInfraEstrutura()
Long idGerado = bancoDeDados.insere(u); u.setId(idGerado); return u; }}
new… Vs Injeção de Dependênciaclass CadastroUsuarioTest {
CadastroUsuario cadastro = ...;
deveInserirNovoUsuarioNoBanco() { Usuario u = new Usuario() //u.set... com valores bem comportados..
cadastro.setBancoDados(...// banco de dados de teste em memória) Usuario salvo = cadastro.salvaUsuario(u)
assertNotNull(salvo.getId()) }}
new… Vs Injeção de Dependêncianew = Forte Acoplamento
difícil manipulação para criação de cenários de teste
Principalmente classes de “infraestrutura” ou “dependência externa”
○ SGBDs, WebServices, Caches, Envio de Emails, etc.
Não crie! receba pronto e use.
Referências Estáticas Vs Instâncias e InterfacesCenário: contador de tempoint contaAteHoje(Data dataNoPassado) {
Data hoje = DateUtils.hoje();
return diferencaEmDias(hoje, dataNoPassado); }
Referências Estáticas Vs Instâncias e InterfacesFazendo um teste...deveContarDiasAteHoje() {
Data dataNoPassado = 1/1/2016
int contagemReal = contadorDeDias.contaAteHoje(dataNoPassado) int contagemEsperada = 20;
// O teste só vai passar se executado em 21/1/2016…. assertEquals(contagemReal, contagemEsperada) }
Referências Estáticas Vs Instâncias e InterfacesViabilizando o teste...Relogio relogio ...// Recebe como Injeção de Dependência
int contaAteHoje(Data dataNoPassado) {
Data hoje = relogio.hoje();
return diferencaEmDias(hoje, dataNoPassado); }
Referências Estáticas Vs Instâncias e InterfacesViabilizando o testedeveContarDiasAteHoje() {
Data dataNoPassado = 1/1/2016
Data hojeFake = 21/1/2016 Relogio mockRelogio = // Mock de Relogio onde hoje() retorna ‘hojeFake’ contadorDeDias.setRelogio(mockRelogio) int contagemReal = contadorDeDias.contaAteHoje(dataNoPassado) int contagemEsperada = 20; // O teste vai passar qualquer dia... assertEquals(contagemReal, contagemEsperada) }
Referências Estáticas Vs Instâncias e InterfacesPontos de atenção
Utils.algoQueTodoMundoUsa()
Por que não objeto.algoQueTodoMundoUsa() ?
Isolar com interfacehoje() { return Calendar.getInstance().getTime()) }
Similar com Integrações Externas (SGBDs, WebServices,etc..)
Responsabilidade: Muita Vs Várias Triviais1 Grande Código Vs 10 pequenos Códigos Integrados
Dado o código abaixo...Usuario salvaUsuario(Usuario u) {
ControleDeAcesso ca = //cria e configura Controle de AcessoOperacaoControleAcesso o = ca.criaOperacaoVerificaPermissaoSalvarUsuario();temPermissao = o.executa()if(temPermissao) {
TransacaoBancoDados tx = bancoDados.criaTransacao();tx.begin()bancoDeDados.insere(u)tx.commit();EnviadoDeEmail enviador = //recupera enviador de emailEmail email = enviador.novoEmail()email.// configura email a enviar..email.envia();Cache cache = // cria e configura Cacheif(cache.estaNoCache(u)) {
cache.invalidaCache(u)}
}}
… O que precisamos fazer para...… Criar cenário de teste para testar:
Se a função persiste o usuário no banco?
Se um rollback é disparado, caso ocorra erro?
Se, somente pessoas autorizadas podem invocar a função?
Se um email é enviado corretamente após usuário inserido?
Se a lógica de Cache está correta?Para testarmos um aspecto do Cadastro de Usuário (persistência, controle de transação, segurança, envio de email) temos que nos preocupar com todos os outros...
Dividir Responsabilidades
Segurança
Transação
Persistência
Cache
Segurança Transação
Persistência
Cache
Cadastro Usuário
Cadastro Usuário
Evite que seu design inviabilize seu teste… crie um teste antes!
AutomaçãoNão desperdice seu tempo...
Automatize tudo que puderSua bateria de testes tende a crescer…
Gaste tempo (muito) pensando em automação de tarefas
Abuse das ferramentas disponíveis
Identifique tarefas rotineiras e repetitivas
Para lhe ajudar
Obrigado
https://www.linkedin.com/in/camiloporto
top related