読者です 読者をやめる 読者になる 読者になる

TDD Boot Campに参加

 年末のドタバタで報告が遅くなってしまったが、先日テスト駆動開発のイベントである"TDD" Boot Campに参加した。ペアプロではC#を選択。

所感

 今回凄いと感じたのは、このイベントが学習の場としてかなり洗練されていたこと。
 例えば、丸一日かけて前半の講義でエッセンスを教え、後半のワークショップでその実体験を積ませるという構成はとても良かった。おかげで「不安をテストに」「一つずつ少しずつ」といったTDDのコツを高い学習効果で身につけることができたと感じる。またペアプロで議論しながら課題を進めていく形式も、限られたコーチ役を補完する上でうまく機能していたと思う。
 一応、実は和田さんのTDD話はデブサミ・オブラブ等のイベントや、あるいはxUTP読書会といった所で結構何度も伺っている。またLasseさんの話も、読書会で読み込んでいる上、日本語版の校正レビューを手伝わせていただいたWorking Effectively with Legacy Codeの内容を踏襲したものだったので、今回の内容はなじみが無い訳ではなかった。けれどもそれでもなお様々なことを学べる濃密さが、今回には確かにあった。

反省点

 ただ貴重なイベントだっただけに、反省点もいくつか。
 一つは今回の機会で学べるものにもっと注力すべきだった。WACATE2009夏と同じく悪い癖が出てしまった形なんだけど、課題をこなすのに気をとられて、機会を活かすという視点に意識をまわせていなかった感がある。もう遅いけど、ペアプロではもっとペアの方と議論したり、ペアの方から意見を聞いたりすれば良かったと後悔。
 あともう少し自分で考えるべきだった。実はt-wada賞のきっかけとなった実時間処理の扱いについては、Slow TestやErratic Testの原因になると問題把握はできたものの、その先を自分で考えず和田さんに聞いてしまった。解決のヒントはxUnit Test Patterns読書会で何度も出ていただけにちょっと悔しい。
 今後似たような機会があれば(これまで同じ事を何度もつぶやいている気もするが)注意していきたい。

最後の課題(仕様変更)について

 なお当日出された課題で今でも気になっているのが、最後のマルチスレッド対応。これに関する自分の答えとしては、ある程度TDDを妥協する必要があるんじゃないかと考えている。

 例えば自分のところでは、平行処理/非同期処理(具体的には疎結合マルチプロセッサシステムやHDL、非同期通信等)の機能保証的なテストは、ModelSim等を使ったタイミング解析やシミュレーション、あるいは並列処理用の検証環境を使った動的解析等に頼ることが多い。種類としては、バグの洗い出しや品質保証などが目的の、従来のソフトウェアテスト的な位置づけになる。

 こうしたテストは、テストや環境の作りこみを必要とする上、時間がかかることも多いので、当然軽快さを要求するTDDとはあまり相性が良くない。が、マルチスレッド対応、という要求に対しては、再現性に問題がある以上、いずれどこかで実施しなければならないアプローチだと思う。
 なので、トータルの生産性を最大化するという観点でみると、TDDでのテストを他の開発工程内テストや、他のテストフェーズに委譲してしまうのもの手だと今のところ感じている(ただマルチスレッドであってもTDDの段階で十分にテスト容易性を確保したり、最低限のテストをしたりする必要があるのは当然として)

 なおSlow Test問題やテスト環境のマルチコア化といった事情も含まれるけど、参加者の方々と話している中で、こういった並列処理/非同期処理/マルチスレッドとテストの絡みは今後さらに話題になりそうな印象を受けた。

xUnit Test Patterns読書会

 ここ最近は組込みばかり扱っている事情で、今回久しぶりに.NETを扱うことになったのだけれど、テストコードを書く点では割とすんなり作業を進められた感がある。当然運営者やスタッフ、ペアの方々の的確な指導も大きいが、思えば一方でxUnit Test Patterns読書会で色々学べていていたのも大きかったと感じる。


 やっぱり今回でもつくづく感じたが、テストコードの変更容易性や保守性は、TDDにとってクリティカルな問題になっていると思う。
 その要因としては、単純に大量のテストコードが生み出される、というのもあるし、コードとテストが密接な対の形をとる、というのもある。いずれにせよ、よく考えないままテストコードを継ぎ足していくと、xUTPでいうFragile TestやSensitivityに陥るリスクを持っている。例えば、リファクタリング容易性のために沢山テストを用意したのに、大量のレッドバーが怖くてかえってリファクタリングしづらくなった、なんて状態になるように。

 xUnit Test Patternsはそうした問題に正にドンピシャで答えてくれる本だと、読書会で読んでいて実感している。(出版時期的には最新鋭とはいえないかもしれないが)この本を読むことで一歩程度先んじている感もある。
 読書会には今後もぜひ参加していきたい。

最後に

 最後に運営者の方々、スタッフの方々にはお礼申し上げます。お蔭で大変充実した一日となりました。