TDDBC 大阪 1.0 について

tddbc

TDD Boot Camp 大阪 1.0( #tddbc ) : ATND
TDD Boot Camp(TDDBC) - TDDBC大阪1.0
#tddbc 大阪 1.0 & 2.0 - Togetter

今年も TDD Boot Camp が開催されることになりました。
見逃すのはもったいないと思ったので、サポートスタッフ(アシスタント成分多め)として参加させていただきました。

いきさつとか心持ちとか

他のスタッフの方々がそうそうたる面子なので、冷静になると気後れしてしまいそうになります。
public な活動してないのは私くらいだったので。
個別の尖ったスキルは無いので、全体を見て回るのが自分の立ち位置のようになっており、今回もそんな感じであっちこっちふらふらさせてもらいました。
目指せグルー人間です。

いろんな事情があって初日の懇親会途中で離脱しました。
参加者の方々、講演者のt_wadaさん、m_sekiさん、hyoshioka さん、スタッフの方々、主催の bufferings さんと後輩社員の方、とてもとてもお疲れさまでした。
あ、楽天カフェテリアは椅子以外はとても素敵な場所でしたので、今後も勉強会の会場としてもっと使われるといいですね。

振り返る

参加者の方のコードを見てると、結構テストコードの重複があるんですよね。
プロダクションコードについては必然的にリファクタリングしてるのに、これはどういうことだろうと思ったのでした。
勝手に推測するとこんな気持ちなんでしょうね。

  • せっかく書いたので捨てるのが惜しい
  • 捨てていいのか分からないので残してる
  • 消すことの不安

なんで TDD するのかと言えば、プログラミングインターフェースを大事にすることで、
宣言型のテストしやすい設計を強制されるからなのだと思うのです。
しかし、手続き型の思考という従来の誘惑から脱却できないと、そのインターフェースの境界を押さえることができません。
なので、「テストケースを書く=できるだけ多くのパターンを網羅したい」となってしまい、お題の示す値域を全て網羅するような大量のテストケースを書いてしまう、というあたりが実態なのかな。
テストケースの位置付けをインターフェース宣言の具体例として考えれば、同値分割したテストケースが最小限となるし、そうでなければ以後の保守の妨げになることはほぼ確実です。
ということで、黄金の回転の目的である「設計の洗練」として、テストコードの設計を洗練することも考えてみるといいんじゃないでしょうか。

某 Web マガジン

私主導になってるせいで締切時空の法則が乱れております orz