お初にお目にかかります。開発室の@ats05です。

2017/10/27に、twadaさんをお招きしたTDDについてワークショップがありました。 当日の流れについては@niisan-tokyo氏がこちらの記事に書かれていらっしゃるので省略させて頂きます。

TDDを体験してみて

twadaさんによるTDDについて講義の後、ペアプログラミングによるTDDを体験してみるワークショップのパートがありました。

TDDのメリット・デメリットなんかは既に様々な場面で議論されてきていることだと思いますので、 ここではあくまで私自身の主観的な感想を書いてみます。

テスト駆動開発というモノ自体は知っていたのですが、実行に移すことは今までありませんでした。理由としては、単純に私自身が「そんなことよりまず動かそうYO!」なスタイルだからですね。

TDDのサイクルは

1. 機能の要件を満たすテストを書く
2. テストが通るようなコードを書く
3. テストが通るままリファクタリングする

という3工程からなります。2番目の工程は、後でのリファクタリングを見込んでいるのでとりあえずは汚いコードでも良いということでした。 結果を担保できる状態で、リファクタリングを進められるという安心感はとても新鮮でした。 今のプロジェクトではテストが組まれていないので、既存機能を改修しようとした時に結構神経を使います。

元の機能を壊さないようにという考慮は目には見えないコストとして発生し、少なからず作業効率を落としていたのではないかな、と思います。

テストは書くべき

講義の中では「 テストコードは仕様書の実装 」という表現がされていました。

あるプロジェクトでは仕様書がなく、途中からアサインされた私は稼働しているコードからそれを読み取る作業が必要でした。 コードを読み解く作業と実装を確かめる作業の効率を上げるためにも、テストは必要だったと思います。

これはプロジェクトを把握しているほど意識しにくくなっていくことだと思います。 これを感じ取るのは後から追加されたメンバーだからですね。

私自身、自分が誰が見てもわかりやすいコードを書けるとは思っていないので、その補完のためにもテストを書くべきだと思いました。

私は本格的にテスト駆動で開発したことがないので、このワークショップで感じたTDDの良し悪しはあくまで想像の域を出ません。テストをきっちりとかければシステムの信頼性はあがるが、果たしてテスト作成にそこまでコストをかけられるのか？という疑問も感じています。

twadaさんのスライドではこう書かれています

• 最初から全部やろうとしない
• テスト駆動にこだわらない

TDDをまるっと導入するのは目前のコストやスピード感などなかハードルが多いと思います。ですので、できる範囲の中でテストを導入できる/するべきタイミングを見計らって、少しずつテストコードを書いていきたいなあと思います。

懇親会

出たかった。出れなかった。
以上です。お疲れ様でした。