• .NET Core 1.1
• NUnit
• JetBrains Project Rider EAP

TDD をやるけど、テストファーストとか、テストコードは書かないといけないよね! とかそういったのは忘れてください。

NUnit などのテスティングフレームワークを使い始めたところから、TDD にいきつくまでに段階があると思ってます。

1. 第一段階

• 今までのやり方に NUnit を突っ込むだけ
• 全てテストコードを書こうとして苦しむ
• この段階はほとんど効果がないばかりか、非効率な場合が多い
• なぜかテストコードを書けば書くほど仕様変更に弱く

2. 第二段階

• 第一段階でやり続けると、テストコードを書いた方がいいところと悪いところの区別がつくようになる
• 効果があるところだけをテストコードを書く
• プラマイゼロから、プラス方向に転じる
• ここまで辿りつけないチームも多い

3. 第三段階

• よりテストコードのカバー範囲を広げるために、テストコードを書く前提の設計をする
• テストファーストはテストコードを先に書くって考えるんじゃなくて、テストを優先して考える感じで
• ここまでできるとかなりプラス方向になる

4. 第四段階

• テストコードを書く行為そのものを設計の一環としてやる
• 試行錯誤の道具として単体テスト
• 実はここで使える技術はかなりいろいろ使える

第四段階のメリットだけを本日は体験し、第一段階でくじけないようにすることと、使えるところはどんどん取り入れていけるようになることを目指す。

単体テスト用の xUnit のたぐいはテストだけでなく、学習にも使うことができる。

• コードを書いてデバッガで追いかける
  • あまり xUnit っぽくないけど、エントリポイントがたくさん書けるので意外と便利
  • 今回は .NET Core だから無理だけど、.NET Framework でフォームを表示してみたり
• アサーションを使った仕様化テスト
  • 知らないメソッドの仕様化テストをしてみる
  • 練習には副作用のない Math クラスがおすすめ
  • 記録に残るので、プロジェクト名とか README を工夫したりすると、まとめノートにもなる

TDD は設計 -> 実装 -> テストの流れを高速で繰り返すことで行うって言われてるけど、やっていない人から見たら、全てが同時というのが多分しっくりくる。サイクルはあるけど、一サイクルがものによっては 30 秒もないので...

題材は書籍リファクタリングがを簡略化したのがモデル。

1. 一番簡単に書けそうなテストコードをひとつだけ書く
2. 失敗を確認
3. それを通すための最低限のコードを書く
4. 成功するまで 3 をがんばる
5. 1 からもう一度

境界値テストとかは意外と面倒なので程々でやめて、次に行く。

TDD による開発では必要十分なテストコードが生まれるので、リファクタリングがとても簡単。リファクタリングをすることで、境界値テストがやりやすくなり、テストの質が上がることを体験する。