No nível mais básico, tudo no Exercism gira em torno dos testes e da prática de testes, que impulsiona a sua implementação e avisa quando um exercício está concluído.
O Pharo tem um ótimo suporte para trabalhar com testes, e com testes incrementais! Você pode rodar qualquer teste de um exercício clicando no orbe ao lado de uma classe ou de um método de caso de teste.
Os orbes de teste têm cores conforme o resultado da última execução dos testes:
- verde se passar
- amarelo se houver falha de asserção
- vermelho se houver erro em tempo de execução ou exceção
Testes ordenados
Os testes nos exercícios do Exercism foram numerados de propósito para dar uma ordem de execução definida (por exemplo, test01_verifySomeProperty, test02_verifyAnotherProperty etc.).
Ao trabalhar em um exercício, é recomendável clicar no orbe do primeiro teste, entender a falha e o que é necessário para fazer esse teste passar, e depois adicionar o código à sua solução para que ele funcione. No Pharo, é bem normal fazer essas mudanças no depurador, onde você tem acesso tanto ao editor de código quanto a uma visão de todas as variáveis e parâmetros que podem ajudar a entender o problema.
NOTA: não é uma prática comum rotular testes com um prefixo de ordenação, e você NÃO deve fazer isso ao escrever testes para o seu próprio projeto.
O Pharo roda tranquilamente com código quebrado, e o depurador simplesmente reabre quando um erro é encontrado (seja um erro de sintaxe, um valor ruim ou até uma classe ou um método ausente). Essa técnica foi uma das principais influências para o desenvolvimento guiado por testes, e você pode ter uma ideia dessa abordagem ao tentar rodar o primeiro teste de qualquer exercício. O depurador vai mostrar imediatamente que a classe da sua solução não foi encontrada (já que você ainda não escreveu nada). Por sorte, há um botão "Create" que ajuda você a adicionar a classe que falta e continuar a execução até ela terminar ou até surgir outro erro.
Com o seu primeiro teste, você logo encontra um segundo erro, já que ainda não escreveu nenhum método. De novo, o botão "Create" do depurador permite definir um método e continuar a execução. Nesse ponto, você também pode clicar mais abaixo no stack trace, revisar os requisitos do teste que está falhando e modificar seu novo método para fazê-lo passar.
Curtindo o depurador
Mais adiante no seu ciclo de desenvolvimento, também pode ser útil clicar mais atrás na pilha e usar o botão "Restart" para retomar a execução do programa em um ponto anterior, para então percorrer o programa passo a passo e ver o que está acontecendo. Essa é uma forma importante e útil de entender por que o seu programa não está funcionando.
Além de ver as variáveis no depurador, você também pode destacar qualquer instrução e clicar em inspect/print para ver o resultado da avaliação dela. Isso pode ser útil ao testar os resultados de um método ou ao examinar o estado interno de um objeto.
Não esqueça que você também pode fazer mudanças no código em execução no depurador, e salvar uma mudança simplesmente faz a execução reiniciar no método que acabou de ser salvo. Isso permite experimentar mudanças e ver os resultados enquanto você ainda está "no calor do momento".
Em resumo, não tenha medo de usar o depurador no Pharo. Nós o vemos como uma ferramenta valiosa que ajuda a entender e experimentar com um problema.
Grupos maiores de testes e automação
Se você precisar rodar grupos maiores de testes, também pode rodá-los pelo menu Package e usar a ferramenta Test Runner (acessível pelo menu World ou digitando <meta> + OU).
Você também pode rodar testes programaticamente a partir do playground, avaliando com print:
AllExercismTests suite run.
Se você quiser saber mais sobre as entranhas dos testes, pode ler sobre o SUnit ou navegar pelo código na hierarquia de TestCase.
Você sabia: o TDD foi inventado no Smalltalk com a introdução da biblioteca de testes SUnit
