Al livello più basilare, in Exercism tutto ruota attorno ai test e al testing: sono loro a spingere avanti l'implementazione e a dirti quando un esercizio è completo.
Pharo offre un ottimo supporto per lavorare con i test, e anche per i test incrementali! Puoi eseguire qualsiasi test di un esercizio facendo clic sull'orb accanto a una classe o a un metodo di un test case.
Gli orb dei test sono colorati in base al risultato dell'ultima esecuzione dei test:
- verde per un test superato
- giallo per un'affermazione fallita
- rosso per un errore di runtime o un'eccezione
Test ordinati
I test degli esercizi di Exercism sono stati numerati di proposito, per dare un ordine di esecuzione definito (ad esempio test01_verifySomeProperty, test02_verifyAnotherProperty e così via).
Quando lavori a un esercizio, ti consigliamo di fare clic sull'orb del primo test, capire il fallimento e che cosa serve per superarlo, e poi aggiungere alla soluzione il codice necessario per farlo funzionare. In Pharo è del tutto normale fare queste modifiche nel debugger, dove hai accesso sia all'editor di codice sia a una vista di tutte le variabili e i parametri che possono aiutarti a capire il problema.
NOTA: non è una pratica comune etichettare i test con un prefisso di ordinamento, e NON dovresti farlo quando scrivi i test per un tuo progetto.
Si può eseguire anche quando è rotto
Pharo esegue senza problemi codice rotto, e il debugger si riapre semplicemente quando incontra un errore (un errore di sintassi, un valore sbagliato o persino una classe o un metodo mancanti). Questa tecnica è stata una delle principali influenze per lo sviluppo guidato dai test, e puoi farti un'idea di questo approccio quando provi a eseguire il primo test di un esercizio. Il debugger mostrerà subito che la classe della soluzione non è stata trovata (dato che non hai ancora scritto nulla). Per comodità, c'è un pulsante "Create" che ti aiuta ad aggiungere la classe mancante e a continuare l'esecuzione, finché non termina o non si incontra un altro errore.
Con il primo test incontri poi un secondo errore, perché non hai ancora scritto nessun metodo. Anche qui, il pulsante "Create" del debugger ti permette di definirlo e di continuare l'esecuzione. A questo punto puoi anche fare clic più in basso nello stack trace, rivedere i requisiti del test che fallisce e modificare il nuovo metodo per farlo passare.
Amare il debugger
Più avanti nel tuo ciclo di sviluppo potresti anche trovare utile fare clic più indietro nello stack e usare il pulsante "Restart" per riprendere l'esecuzione del programma da un punto precedente, così da poter poi avanzare passo passo nel programma e vedere cosa succede. È un modo importante e utile per capire perché il programma non funziona.
Oltre a vedere le variabili nel debugger, puoi anche evidenziare qualsiasi istruzione e fare clic su inspect/print per vedere il risultato della sua valutazione. Può essere utile quando verifichi i risultati di un metodo o quando esamini lo stato interno di un oggetto.
Non dimenticare che puoi anche modificare il codice in esecuzione nel debugger: salvare una modifica fa semplicemente ripartire l'esecuzione nel metodo appena salvato. Così puoi sperimentare le modifiche e vederne i risultati mentre sei ancora «sul pezzo».
In sintesi, non aver paura di usare il debugger in Pharo: lo consideriamo uno strumento prezioso che aiuta a capire un problema e a sperimentare su di esso.
Gruppi di test più grandi e automazione
Se ti capita di dover eseguire gruppi di test più grandi, puoi farlo anche dal menu "Package" oppure usare lo strumento "Test Runner" (accessibile dal menu "World" o digitando <meta> + OU).
Puoi anche eseguire i test a livello di codice dal playground, valutando l'espressione con print:
AllExercismTests suite run.
Se vuoi saperne di più sul funzionamento interno dei test, puoi leggere qualcosa su SUnit o sfogliare il codice nella gerarchia di TestCase.
Lo sapevi: il TDD (sviluppo guidato dai test) è stato inventato in Smalltalk grazie all'introduzione della libreria di test SUnit
