VS2005環境でのNAgile - DSLとユニットテスト (>_<)

自動生成されたコードに対するユニットテストは必要か？

これからはDSLから自動生成されるコードの塊を使用する機会がどんどん増えてくるだろう。そのコードの塊を使用する立場としてなんとなく動いたからそれでいいといった姿勢でいいのだろうか。何か機能を実装する際に問題にぶち当たればネットを検索してその解決方法の背景を深く理解することなく適用してしまうような開発スタイルに慣れてしまっている開発者なら容易にそのような姿勢をとってしまう事が想像できる。

幸いDSLから自動生成されたソースコードは読むことができる。その背後でどんなコードが動いているのかを学習することは必要だ。そのための手段としてTDDはとても上手く機能する。また自動生成されたコードを使用する場合でも「どのような機能を実現するためにDSLモデルを作成しようとしているか」を理解してから作業を開始するはずだ。例えばTableAdapterの場合であればどのようなCRUDメソッドを実装しようとしているか、メソッドの名前はどんな名前にするかは事前に設計できる事柄であり、その設計を単体テストとして先に実装することは決して難しいことではない。

これからの世代の開発者には、自力で沖合いまでパドリングしてから波に乗るといったあたりまえの手順で開発を行うための十分な時間が与えられることは稀だろう。.NETの案件があるからオブジェクト指向を理解してパターンを学習してから開発を始めるといったことは時間の制約の面から許されない。サーフィンをしたことがないようなひよっ子が高性能なサーフボードを支給され大海のど真ん中にヘリで連れて行かれて「さぁ波に乗ってみろ。」というような局面も大いに考えられる。

そこでできることは自分で道具の使い方を試して覚えていくことだけだ。「ネットで検索しても出てこないので、使い方がわかりません。」と泣き言を言っている暇があれば、体で覚えるほうが手っ取り早い。しかし実装コードで試してデバッグで動作確認ではどのような意図をもってその道具が作られているのかを理解するには及ばない。この方法では「なんとなく動いたから」で終わってしまうのだ。

ではどうすればいいのか。僕の答えはシンプルだ。

自分が解決しようとしている問題は何で、その解決のための道具がDSLから自動生成されるコードで、それを使用して得られるアウトプットは何か。これを理解してから波に乗ってみろ。ほらそれを実現するために君にはTDDがあるじゃないか。