こないだTDDBootCampで、プライベートの関数に直アクセスできるという
素敵な機能の話があって、Twitterにて、
「そいつは、プライベートアクセサーっていうんだぜ！」（一部誇張）
ということを教えてもらったので、こいつぁ試してみるかと。
使い方を調べてみると、ちゃんとMSDNにつながるのね
http://msdn.microsoft.com/ja-jp/library/bb385974.aspx
http://msdn.microsoft.com/ja-jp/library/ms184807.aspx
（MSDNもかっこよくなっとる・・・）
といっても、ちょっっと試してみただけなんだけど簡単に使えるのね。
最初、プロキシクラスが とか 中継してくれるとか、
いろいろ手続き処理を書きながら呼ぶのかと思ったら、
実際のやり方は非常に簡単で、テスト元のクラスを作ってから、
クラスのコードの中で右クリック（コンテキストメニュー）から、
単体テストの作成を選ぶだけ
クラスを指定してやれば、すべてのメソッドについて作ってくれるし
メソッド名を指定すれば、そのメソッドだけ作ることも可能
どれを生成するかは、メニューを出すとき、もしくは、その後に
表示されるダイアログで、必要なものにチェックいれると
自動で生成してくれるという簡単さ。
自動生成されるコードには、TODOが書かれてるので、
簡単な関数であれば、そのとおり書いていけば単体テストの完成なのかな。
同じこと２回やると、XxxxxTest1みたいに数字がついて生成されちゃうので
気を付ける。（上書きでの生成はしない）
自動生成のコードは、引数用の変数が自動生成される
（引数名そのままの変数）ので、そこの値にテスト用の値、
expectedに予想される結果の値を入れれば、
メソッドのテストが完成する。
戻り値なしの場合は
Assert.Inconclusive("値を返さないメソッドは確認できません。");
って自動生成されるので、例外を受け取るように自分で
ExpectedException を追加する必要がある。
さて、自分の思ったところは、
TDDの場合は、テスト –> 関数の本体のみ実装 –> Red –> Green
と思ってたので少し流れが違うのかな・・・
自動生成だと、ユーザーが実際に使うに対してというよりは、
メソッドの動作を確認するっていう観点のテストになるので
リファクタリングとかで、共通化する部分が出てきて
そこを切り出すときに、関数単体のテストもしといたほうがいいな～って
思ったら、テストの自動生成の出番かな
（関数がprivateなら、プライベートアクセサーだなｗ）
試しにFizzBuzzで試したコードがあるけど、どこにおくかいまいち決めらんないので
要望があれば出すことにしようｗ