もっとも基本的なところでいえば、Exercismはテストとテストを進めることが中心です。テストが実装を前に進め、演習が完成したときを教えてくれるからです。
すぐにわかるフィードバック
Pharoにはテストを扱うための強力なサポートがあり、少しずつテストを進めていけます！ 演習のテストは、テストケースのクラスやメソッドの隣にあるorbをクリックすれば実行できます。
テストorbは、最後にテストを実行した結果に応じて色が変わります。
- 合格なら緑
- アサーションの失敗なら黄色
- 実行時エラーや例外なら赤
順番が決められたテスト
Exercismの演習にあるテストには、実行順序を決めるためにあらかじめ番号が振られています（例：test01_verifySomeProperty、test02_verifyAnotherPropertyなど）。
演習に取り組むときは、まず最初のテストのorbをクリックし、なぜ失敗したのか、合格するには何が必要なのかを理解してから、動くように解答へコードを追加していくのがおすすめです。Pharoでは、こうした変更をデバッガーの中で行うのがごく普通のことです。デバッガーでは、コードエディターも、問題の理解に役立つ変数や仮引数の一覧も見ることができます。
注意：テストに順序の接頭辞を付けるのは一般的な習慣ではなく、自分のプロジェクトでテストを書くときには、こうしてはいけません。
壊れていても動かせる
Pharoは、壊れたコードでも平気で動きます。エラー（構文エラー、不正な値、クラスやメソッドが見つからない場合など）が起きると、デバッガーがただちに開き直すだけです。この仕組みはテスト駆動開発に大きな影響を与えました。どの演習でも、最初のテストを実行してみれば、このやり方を少し体験できます。デバッガーは、解答のクラスが見つからないことをすぐに示します（まだ何も書いていないからです）。便利なことに、「Create」ボタンがあり、これを使えば足りないクラスを追加して、実行が終わるか別のエラーが起きるまで動かし続けられます。
最初のテストでは、まだメソッドを何も書いていないので、次は2つ目のエラーに出会います。ここでも、デバッガーの「Create」ボタンでメソッドを定義し、実行を続けられます。この時点で、スタックトレースのさらに下のほうをクリックして、失敗したテストの要件を確認し、新しいメソッドを修正して合格させることもできます。
デバッガーを好きになろう
開発を進めていくうちに、スタックのもっと前のほうをクリックし、「Restart」ボタンでプログラムの実行を前の地点から再開すると便利だと気づくかもしれません。そうすれば、プログラムを1ステップずつ動かして、何が起きているのかを確かめられます。これは、プログラムがなぜ動かないのかを理解するための、重要で役立つ方法です。
デバッガーで変数を見られるだけでなく、任意の文をハイライトしてinspect/printをクリックすれば、その評価結果を確認できます。これは、メソッドの戻り値を調べたいときや、オブジェクトの内部状態を確認したいときに役立ちます。
デバッガーでは、実行中のコードをそのまま変更できることも忘れないでください。変更を保存すると、いま保存したメソッドの実行が再開されるだけです。これにより、まさにその場で変更を試し、結果を確かめられます。
まとめると、Pharoのデバッガーを恐れる必要はありません。問題を理解し、あれこれ試すのに役立つ、価値ある道具だと考えています。
より大きなテスト群と自動化
より大きなテスト群を実行する必要があるときは、Packageメニューから実行する方法と、Test Runnerツールを使う方法（Worldメニューから開くか、<meta> + OUと入力します）があります。
プレイグラウンドからprint評価で、テストをプログラム的に実行することもできます。
AllExercismTests suite run.
テストの内部についてもっと知りたければ、SUnitについて読んだり、TestCase階層のコードを眺めたりしてみてください。
知っていましたか： TDDは、SUnitテストライブラリの登場によってSmalltalkで生まれました
