testes de software de a a z

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


deveInserirNovoUsuarioNoBanco() {

}

}

Vou começar fazendo a parte que insere os dados no banco…

Começando no cenário de inserir um novo usuário...


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 {





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 CadastroUsuario {

usuario salvaUsuario(Usuario u) { Long idGerado = bancoDeDados.insere(u); u.setId(idGerado); return u; }}

Cenário após a codificação








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 {





● 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...


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 {



cadastro.setBancoDados(...// banco de dados de teste em memória) Usuario salvo = cadastro.salvaUsuario(u)


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

Email

Cache

Segurança Transação

Persistência

Email

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

Para saber mais...http://lmgtfy.com/?q=software+test+tools

http://lmgtfy.com/?q=software+test+tools

Obrigado

https://www.linkedin.com/in/camiloporto