- O que queremos dizer com testar?
- Quando testamos? - Como escolhermos que lógica testar?
- Como escolhermos quais dados testar?
+-------O------+
/ \
-> Estresse < > Execução de Testes
\ /
+-------O------+
Estresse afeta negativamente a execução de testes, que afeta negativamente a estresse.
- Escreva um teste automatizado o máximo possível
- Em nada - Testes devem ser independentes (sempre que possível)
- Antes de começar, escreva uma lista de todos os testes que sabe que terá que escrever. - Nunca dar um passo à frente a menos qu esaibamos que nosso pé está indo para terra firme.
- Se surgirem novos casos de testes adicione a lista. - Nunca pare com um teste quebrado antes de pegar o próximo item da lista.
- Antes de escrever o código que vai ser testado.
- Quando testamos primeiro reduzimos o estresse.
- Por onde você deve começar a construir um sistema? Com histórias de que quer ser capaz de contar sobre o sistema terminado.
- Por onde você deve começar a escrever um pedaço de funcionalidade? Com testes que quer que passem com código terminado.
- Por onde você deve começar a escrever Testes? Com as asserções que passaro (serão bem-sucedidas) quando estiver feito.
- Antes de escrever o teste (pelo menos ter em mente quais as asserções devem ter no teste)
- Use dados que façam os testes fáceis de ler e seguir
- Nunca usar a mesma constante para siginificar mais de uma coisa - Uma alternativa para dados de testes são dados realistas (o que demanda de um teste de integração/aceitação ou ler dados de algum lugar)
- Inclua resultados esperados e reais no próprio teste e tente fazer seu relacionamento evidente. - Você está escrevendo teste para um leitor e não para um computador - Evite calculos nos testes/asserções
- Quando você escreve testes - Onde você escreve testes - Quando você para de escrever testes
- Do conhecido ao desconhecido
- Top-Down (Começar com um teste que representa um caso simples)
- Bottom-Up (Começar com pedaços pequenos e ir agregando aos poucos)
- Comece com uma variante de uma operaço que no faz nada.
- Como reduzir uma malha de polignos? (existem polignos que não podem ser reduzidos, logo esse seria um bom início)
- Peça e dê explicaçes em termos de testes.
- Dando Explicação: "Se eu tiver um XXX com um YYY então quer dizer que deve resultar em 50."
- Pedindo Explicação: "Quando eu tenho um XXX com um YYY então a resposta 50?"
- Você quer utilizar uma biblioteca de logs. Então crie testes para ver se você está manjando da api.
- Os beneficios é garantir que se você usar o que você testou não irá quebrar seu software, e quando houver uma atualização você sabe fácilmente o que vai preisar alterar para se adequar a essa atualização.
- Quando uma ideia tangencial emerge, adicione um teste à lista e volte ao assunto
- Se você estiver travado em uma parte e novas ideias surgirem. Adicione a lista de tarefas e termine o que está te travando.
- Escreva o menor teste possível que falhe e que, uma vez rodado, será reparado.
- As vezes esquecemos ou não pensamos em alguns casos de testes. A melhor maneira de resolver isso é criar um teste a medida que os bugs aparecem.
- Teste de regresso é só uma jeito do seu sistema dizer "Você ainda no terminou de me projetar completamente"
+-------O------+
/ \
-> Fadiga < >Julgamento
\ /
+-------O------+
Fadiga afeta negativamente o Julgamento, que afeta negativamente a fadiga.
- Faça uma pausa
- Tome um drink
- Dê uma volta
- Durma
- Metodologia do Chuveiro (se você sabe o que escrever então escreva, se não sabe tome uma ducha pra relaxar e fique no chuveiro até saber o que digitar)
- Metodologia do Chuveiro aprimorada com TDD
- Se você sabe o que escrever faça uma Implementação Óbvia (Obvious Implementation).
- Se não sabe o que escrever então Faça de Conta(Fake It).
- Se o projeto certo ainda não está claro então Triangule (Triangulate).
- Se você ainda não sabe o que escrever ento pode tomar aquela ducha.
- Jogue fora o código e comece novamente
- Se o Break não funcionou então repense se ainda faz sentido o código que você está travado.
- Se preocupe com o ambiante (você no consegue codar em uma posição ou cadeira desconfortável)
- Detalhes para escrever testes
- Escreva um caso de teste menor que represente a parte que não funciona no caso de teste maior.
- Por que o caso de teste está grande?
- O que eu poderia ter feito diferente para o caso de testes ser menor?
- Se houver uma forma de escreve-lo menor então Do Over.
- Crie uma verso de faz de conta do recurso que responde com constantes.
- Tenha o objeto que está sob o teste se comunicanco com um caso de teste, em vez do objeto que ele espera.
- Por exemplo em um cenário de publish/subscribe fazer com que o listener seja a classe de teste. (TesteCase)
- Mantenha um registro (log) em uma string e, quando uma mensagem for chamada, acrescente-a à string.
- Invoque-o de qualquer forma, por exemplo com um objeto especial que lança uma exceção em vez de fazer o trabalho.
- Deixe o último teste quebrado... (hehehe)
- Analogia com "Terminar uma sessão de escrita no meio da frase. Ao retomar a escrita você olha para a frase pela metade e precisar descobrir o que estava pensando quando escreveu."
- Deixe todos os testes rodando... (Meio contraditório não? kkk)
- Quando você está trabalhando em equipe você não tem todos os detalhes do código desde a ultima vez que você viu.
- Antes de começar uma sessão rode certifique-se de que todos os testes estão passando.
- Antes de finalizar uma sessão rode certifique-se de que todos os testes estão passando. Caso não passe a regra simples é jogar seu trabalho fora e começar novamente (O teste não passar é uma evidencia muito forte de que você não sabia o suficiente para programar o que acabou de programar). Uma alternativa é tentar corrigir, mas se isso estiver levando muito tempo jogue fora e comece de novo.
- Detalhes de como fazer o código funcionar (mesmo se o resultado não é algo com o qual queria conviver por mais de uma hora)
Fake It (Til you make it) - (Qual sua primeira implementação uma vez que tem um teste que não funciona?)
- Retorne uma constante
- Depois de ter o teste rodando, gradualmente transforme a constante em uma expressão usando variáveis.
- O importante é lembrar de remover a duplicidade de código (seja dados, constantes ou métodos)
- Abstraia quando tiver dois ou mais exemplos.
- Ter duas asserção para remover uma constante (Fake It).
- Validar a abstração.
- Exemplo: inverter a lógica ou em caso de calculos usar outros fatores asserções para 1+3 e para 3+4 (precisamos fazer o teste passar para as duas asserções)
- Usado geralmente quando não se sente seguro sobre a abstração correta.
- Apenas implementando-as.
- Quando você tem certeza de como implementar uma operação
- Se Obvious Implementation não funcionar (red bar). Faça passos menores (Fake It, Triangulate).
- Ao usar Obvious Implementation podemos focar demais em ter um código limpo e esquecer que ele tem que funcionar e isso pode ser frustrante. Lembre-se sempre de red/green/refactor. Se estiver muito constantemente em red, mude a estratégia para Fake It ou Triangulate.
- Implementando sem a coleção primeiro, então faça funcionar com coleções.
- Padrões para frameworks xUnit
- O valor esperado da asserção geralmente vem primeiro
- Escreva uma expressão booleana que automatize seu julgamenteo sobre se o código funciona ou não.
- Seja específico nas asserções (ao invés de assertTrue( z.area() != 0 ) use assertTrue( z.area() == 50) ou melhor assertEquals(50, z.area())
- Use mensagens quando as asserções falharem
- Converta as variáveis locais nos testes para variáveis de instâcia.
- Use
setUp() - Isso ajuda a remova a duplicação no código de teste (se necessário). O lado negativo é ter que lembrar o que está no
setUp()
- Utilize o método
tearDown()para liberar recursos - Cada testes deve deixar o mundo extamente no mesmo estado de antes de rodar.
- Com um método cujo o nome começa com
test(ou alguma outra forma de marcação)
- Pegue a exceção esperada e ignore-as, falhando apenas se a exceção não é lançada.
try{
// do something
fail()
}catch( IllegalArgumentException e ){
}
- Faça uma suíte de todas as suítes
- Uma para cada pacote, e uma agregando os pacotes de testes da aplicação inteira.
- Projetos em TDD requer um olhar ligeiramente diferente sobre os padrões de projeto (lembrar sempre da fase de refactor)
Command (O que você faz quando precisa que uma invocação de uma computação seja mais complicado que uma simples chamada de método?)
- Faça um objeto para a computação e invoque-o. - O Command é considerado um objeto de primeira classe (uma função que pode ser passada por parâmetro, e pode ser usado como dados). - O Command é muito similar ao Strategy uma diferença entre ele é que a ideia do strategy é simplesmente executar um método. Já no command podemos receber e manter valores em variáveis de instancia e o método definido na interface no precisa ter argumento.
- Pode ser convertido em lambda, closure, blocks ou similares.
Value Object (Como você projeta objetos que serão amplamento compartilhados, mas para os quais a identidade não é o importante? )
- Configure seu estado quando são criados e nuca mode-o. - Operações no objeto sempre retornam um novo objeto. - Deve implementar critérios de igualdade e hashing (se for necessário).
- Crie um objeto que represente o caso especial. Dê a ele o mesmo protocolo dos objetos regulares. - Isso evita verificações nulas espalhadas pelo código
public boolean setReadOnly(){
SecurityManager guard = System.getSecurityManager();
if(guard != null){ // vamos remover esse if com NullObject
guard.canWrite(path)
}
return fileSystem.setReadOnly(this);
}
//-------//-------//
class LaxSecurity extends SecurityManager {
public void canWrite(String path){
// do nothing
}
}
// Method in System
public static SecurityManager getSecurityManager(){
return security == null ? new LaxSecurity(): security;
//-------/Nova implementação/-------//
public boolean setReadOnly(){
SecurityManager security = System.getSecurityManager();
security.canWrite(path); // Sem if
return fileSystem.setReadOnly(this);
}Template Method (Como você representa a sequência invariável de uma computação enquanto prepara refinamentos futuros?)
- Escreva um método que é implementado inteiramente em termos de outros métodos.
- Deixar condicionais explícitas pelo código pode ser um problema pois elas se proliferam.
- Podemos extrair uma interface e criar objetos que possam ser plugados em função dessa variação.
//Exemplo de editor gráfico:
// Se você está sobre uma figura então ao clicar e movimentar o mouse deve mover a imagem
// Se você não está sobre uma figura está selecionando um grupo de figuras e ao movimentar o mouse deve ser redimensionado o retangulo (ref. a area da seleção)
//Sem Plugable Object
Figure selected;
public void mouseDown(){
selected = findFigure();
if (selected != null )
select(selected)
}
public void mouseMove(){
if (selected != null ){
move(selected)
}else{
moveSelectionRectangle()
}
}
public void mouseUp(){
if (selected == null)
selectAll()
}
// Com Plugable Object
Figure selected;
private SelectionMode mode;
public void mouseDown(){
selected = findFigure();
if( selected != null)
mode = SingleSelection(selected);
else
mode = MultipleSelection();
}
public void mouseMove(){
mode.mouseMove();
}
publc void mouseUp(){
mode.mouseUp();
}
- Armazene o nome do método e invoque-o dinamicamente.
- Basicamente Reflection
- Crie um objeto em um método em vez de usar um construtor
- Construtores em java são pouco expressivos
- Desvantagem é a indireçãoo. Você tem que lembrar que o método está realmente criando um objeto mesmo que não pareça um construtor.
- Introduza um novo objeto com o mesmo protocolo de um objeto existente, mas com uma implementação diferente.
- Tipos de Imposter
- NullObject
- Composite
Composite (Como você implementa um objeto cujo comportamente é a composição do comportamento de uma lista de outros objetos?)
- Torne-o um imposter para objetos componentes.
- Faça o objeto ser tratado igual (utilizando uma interface comum) se ele for um único objeto ou um coleção do mesmo.
Collecting Parameter (Como você coleta os resultados de uma operação que está espalhada em vários objetos?)
- Adicione um parâmetro à operação em que o resultado serão coletados.
- Nos métodos que dos objetos que você quer coletar os resultados, receba um parâmetro e faça com que os métodos populem esse parâmetro. Ao final da computação você terá todos os dados que os métodos desses objetos popularam em um só parâmetro.
- Não faça isso.
- Seus programas agradecerão por aproveitar o tempo para pensar sobre o projeto em vez disso.
- Em TDD usamos refatoração de uma forma um pouco diferente. Geralmente refatorar não pode mudar a semântica do programa sob qualquer circustância. Em TDD as circustâncias que nos importamos são os testes (que já passaram). (Que louco num é? kkk)
- Podemos mudar constantes por variáveis no TDD e com consciênci, chamar essa operação de refatoração, pois não muda o conjunto de testes bem-sucedidos.
- A única circunstância sob qual a semântica é preservada pode, realmente ser aquele caso de teste em particular. Quando outro caso de teste que estivesse funcionando falharia. Contudo, não temos esses testes ainda, então não precisamos nos preocupar com eles.
- Uma refatoração com respeito aos testes é o mesmo quem uma refatoração com respeito a todos os testes possíveis.
- Unifique-os apenas quando eles forem absolutamente idênticos.
- Evite refatorações que forcem você a examinar o fluxo e os valores dos dados cuidadosamente. (Refatorações com saltos de fé. Aquelas quais exigem um longo raciocínio e esse conduz você a acrediar que aquela mudança que está prestes a fazer não mudará qualquer resposta.)
- Níveis de escalas para refatorações de duplicidades:
- Duas estruturas de repetições são similares. Fazendo-as idênticas, você pode mesclá-las.
- Dois desvios de uma condicional são similares. Faznedo-os idênticos, você pode elminar a condicional.
- Dois métodos são similares. Fazendo-os idênticos, você pode elminar um.
- Duas classes são similares. Fazendo-as idênticas, você pode elminar uma.
- Primeiro, isole a parte que tem que mudar.
- A ideia é pensar como se fossemos um cirurgião em um processo cirurgico. O paciente inteiro está coberto e estamos somente com a parte que vai ser operada exposta. Temos uma concentração melhor no ponto isolado que iremos mexer.
- Algumas formas de prover Isolate Change:
- Extract Method
- Extract Object
- Method Object
- Duplique os dados temporariamente enquanto estiver refatorando.
- Existem duas formas de fazer:
- Interna para Externa (Implementação primeiro):
- Adicione uma váriavel de instância no novo formato
- Configure a variável no novo formato em todo lugar que configurou o antigo formato
- Use a variável no novo formato em todo lugar que usou o antigo formato.
- Apague o antigo formato.
- Mude a interface externa para refletir o novo formato
- Externa para Interna (Api primeiro):
- Adicionar um parâmetro no novo formato.
- Traduzir o parâmetro de novo formato para a representação interna do formato antigo.
- Apagar o parâmetro no formato antigo.
- Substituir usos do formato antigo pelo formato novo.
- Apagar o formato antigo.
- Interna para Externa (Implementação primeiro):
- Tranforme uma parte pequena dele em um método separado e chame o novo método.
- Substitua uma invocação de método pelo próprio método.
- Crie uma interface contendo as operações compartilhadas.
- Adicione-o à classe à qual ele pertence, e então invoque-o.
Method Object (Como você representa um método complicado que requer muitos parâmetros e variáveis locais?)
- Faça um objeto a partir do método.
- Se o método está em uma interface, adicione o parâmetro a interface primeiro.
- Adicione o parâmetro ao método
- Use os erros de compilação para ver qual código está sendo chamado e que você precisará mudar.
Method Parameter to Constructor Parameter (Como você troca um parâmetro de um método ou métodos para o construtor?)
- Adicione um parâmetro ao construtor
- Adicione uma variável de instância com o mesmo nome do parâmetro.
- Atribua a variável no construtor
- Uma a uma, converta as referências de "parameter" para "this.parameter"
- Quando não existirem mais referências ao parâmetro, elimine o parâmetro do método e de todos aquelesd que o chama.
- Remova os agora os "this" das referências.
- Renomeia a variável corretamente.
- Questões para você ponderar sobre como itegrar TDD em sua própria prática.
- Existem duas perguntas:
- Quanto terreno cada teste deveria cobrir?
- Por quantos estágios intermediários você deveria passar enquanto refatora?
- Você pode escrever testes de uma forma que seu teste incentive você a adicionar só mais uma linha e algumas poucas refatorações.
- Você pode escrever teste de uma forma que ele incentive você adicionar muitas linhas e horas de refatoração.
- Em TDD não existe uma resposta certa (escrita na pedra) para essa questão. E conforme você tenha fluência em TDD você pode escolher qualquer uma das abordagens. Indo mais rápido (dando passos maiores) quando se sentir confortavel e ir diminuindo o rítimo quando as coisas não saem como o planejado, ou, se não estar confortável começar devagar e ir aumentando seus passos.
- Escreva testes até que o medo se torne tédio - Philip
- TDD é um laço de feedback e requer que você encontre a resposta sozinho.
- Porém o que eu sempre devo testar? Se em seu código tem um dos itens abaixo deve ter um testes:
- condicionais
- laços
- operações
- polimorfismo
- A menos que você tenha razão para desconfiar não teste código dos outros.
- Essa é a pergunta que todos procuram e é a mais difícil de responder (inclusive não tem uma resposta certa. (não aqui) ). Porém abaixo tem uma lista com indicações de que seus teste ou seu projeto está ruim para testar.
- Longo código de configuração (se você gasta muitas linhas criando objetos para uma asserção simples então algo está errado).
- Duplicação de condiguração (Se você não puder encontrar facilmente um lugar comum para código de configuração comum então há muitos objetos fortemente entrelaçados.)
- Testes de longa execução (Sua suite de teste deve lebar no máximo 9,8m/s² (aceleração da gravidade na Terra aproximadamente 10 minutos caso contrário ajuste para rodar nesse tempo) . Se sua suite de testes demoram muito para rodar ela será executada com menos frequência, se isso acontecer pode ser que tenha testes nessa suite que parem de funcionar e você só descubra quando rodar ela novamente.)
- Testes frágeis (Teste que quebram inesperadamente. Isso pode ocorrer quando uma parte do sistema está surpreendentemente afetando a outra)
- Paradoxo: Não considerando o futuro do seu código, voí torna seu código muito mais provável de ser adptável no futuro.
- A primeira feature entra. Ela é implementada simples e diretamente, logo, estea pronta rapidamente e com alguns bugs.
- A segunda feature, e uma variação da primeira, entra. A duplicação entre as duas fatures é posta em um lugar, ao passo que a diferençå tende a entrar em lugares diferentes(métodos ou mesmo classes diferentes)
- A terceira feature, e uma variação da segunda entra. A lógica comum é plausível de ser reutilzada, talvez com alguns ajustes. A lógica única tende a ter um habitat óvibio em um método diferente ou em uma classe diferente.
- O OCP (SOLID) facilita muito na manutenção dessas variações.
- Kent Beck fez o 6 testes para o problema citado no livro de Bob Binder (Testing Object-Oriented System). Enquanto o próprio Bob Binder escreveu 65 testes. (Dado 3 inteiros que representes os lados de um triângulo retorne 1 se for um triângulo equilátero, 2 se for um trângulo isósceles, 3 se for um triângulo escaleno e lance uma exceção se o triângulo não estiver bem formado)
- Aqui você pode pensar em MTBF (Mean Time Between Failure). Se você quer aumentar MTBF de 10 anos para 100 anos então você terá que testar coisas muitos improvaveis. No exemplo dos inteiros poderiamos ter um testes para verificar o tamanho máximo de um inteiro para um ou ambos os lados de um triângulo. Agora se isso faz sentido ou não depende muito do seu cenário.
- Quanto mais testesm, melhor, mas se dois testes são redundantes um com respeito ao outro, deveria manter ambos?
- Confiança. Nunca apague um teste se isso reduz sua confiança no comportamento.
- Comunicação. Se você tem dois testes que exercitam o mesmo caminho de código, mas falam de cenários diferentes para um leitor, deixe-ps em paz.
- Se você tem dois testes que são redundantes com respeito a confiança e comunicação, apague o menos útil dos dois.
Como a linguagem e a IDE influenciam TDD? (Tente TDD em Java com IntelliJ. Agora tente TDD em Javascript com Vim.)
- Em linguagenes e IDE que não facilitam tanto o ciclo de feedback do TDD (red/green/refactor), seremos tentados a dar passos maiores.
- Cubra mais terreno com cada teste.
- Refatore com menos passos intermediários.
- Em linguagens e IDE em que os cliclos de feedback do TDD é abundante, somos motivados a experimentar mais. Isso ajuda você a ir mais rápido ou chegar a soluções mais rápido.
- Que novos testes você teria que escrever ?
- Que novos tipode de refatorações você precisaria ?
- Com TDD eliminamos duplicação, você cria objetos menores, e esses objetos podem ser testados isoladamente e independente do tamanho da aplicação/sistema.