Na sua forma mais elementar, o Exercism é tudo sobre testes e testar, porque é isso que faz avançar a tua implementação e te diz quando um exercício está completo.
O Pharo tem um excelente suporte para trabalhar com testes, e para testes incrementais! Podes correr qualquer teste de um exercício clicando no orbe ao lado de uma classe ou método de teste.
Os orbes de teste têm cor conforme o resultado da última execução dos testes:
- verde quando o teste passa
- amarelo quando falha uma asserção
- vermelho quando há um erro de execução ou uma exceção
Testes ordenados
Os testes dos exercícios do Exercism estão numerados de propósito, para dar uma ordem de execução definida (por exemplo, test01_verifySomeProperty, test02_verifyAnotherProperty, etc.).
Quando estás a trabalhar num exercício, recomendamos que cliques no orbe do primeiro teste, compreendas o que falhou e o que é preciso para o fazer passar e, em seguida, acrescentes o código à tua solução para que funcione. No Pharo, é perfeitamente normal fazer estas alterações no depurador, onde tens acesso tanto ao editor de código como a uma vista de todas as variáveis e parâmetros que te podem ajudar a compreender o problema.
NOTA: não é prática comum etiquetar os testes com um prefixo de ordenação, e NÃO deves fazer isso quando escreves testes para os teus próprios projetos.
O Pharo corre sem problemas com código avariado, e o depurador volta simplesmente a abrir-se quando surge um erro (um erro de sintaxe, um valor inválido ou até uma classe ou método em falta). Esta técnica foi uma das principais influências do desenvolvimento orientado por testes, e podes ter uma ideia desta abordagem quando experimentares correr o primeiro teste de qualquer exercício. O depurador mostra imediatamente que a tua classe de solução não foi encontrada (porque ainda não escreveste nada). Por conveniência, há um botão "Create" que te ajuda a adicionar a classe em falta e a continuar a execução até esta terminar ou até surgir outro erro.
Com o primeiro teste, encontras a seguir um segundo erro, porque ainda não escreveste nenhum método. Mais uma vez, o botão "Create" no depurador permite-te definir um e continuar a execução. Nesta altura, também podes clicar mais abaixo no traço da pilha, rever os requisitos do teste que está a falhar e modificar o teu novo método para o fazer passar.
Vais adorar o depurador
Mais tarde no teu ciclo de desenvolvimento, também pode ser útil clicares mais atrás na pilha e usares o botão "Restart" para retomar a execução do programa num ponto anterior, para depois poderes avançar passo a passo pelo programa e ver o que se está a passar. É uma forma importante e útil de compreender porque é que o teu programa não funciona.
Além de veres as variáveis no depurador, também podes selecionar qualquer instrução e clicar em inspect/print para ver o resultado da sua avaliação. Isto pode ser útil para testar os resultados de um método ou para examinar o estado interno de um objeto.
Não te esqueças de que também podes alterar código em execução no depurador, e guardar uma alteração faz simplesmente com que a execução recomece no método que acabaste de guardar. Isto permite-te experimentar alterações e ver os resultados enquanto ainda estás "no momento".
Em resumo, não tenhas medo de usar o depurador no Pharo: consideramo-lo uma ferramenta valiosa que ajuda a compreender e a experimentar um problema.
Grupos de testes maiores e automatização
Se alguma vez precisares de correr grupos de testes maiores, também os podes executar a partir do menu Package ou usar a ferramenta Test Runner (a que acedes a partir do menu World ou escrevendo <meta> + OU).
Também podes correr testes programaticamente a partir do playground, com print evaluating:
AllExercismTests suite run.
Se quiseres saber mais sobre o funcionamento interno dos testes, podes ler sobre o SUnit ou explorar o código na hierarquia TestCase.
Sabias que: o TDD foi inventado no Smalltalk, com a introdução da biblioteca de testes SUnit
