今さらではあるのですが、先日、昨年の de:code 2017 で t_wada さんが公演されていたテスト駆動開発の動画をみんなで鑑賞するという会をやってみました。
今日は de:code2017 のテスト駆動開発の動画をみんなで鑑賞してわいわい意見を述べ合う場をやってみたけど、なかなか有意義な時間になってよかった https://t.co/wOrLq0vUZQ
— kntmr (@knt_mr) September 7, 2018
とはいえ、実際、de:code 2017 には参加しておらず、この動画も今年の春くらいに初めて見たのですが、内容がとてもよかったので「他のひとたちにも観てもらおう」と思ったのがきっかけです。
内容としては基本的なものかと思います。が、観たことがないという方はぜひ一度ご覧いただければと思います。途中、ライブコーディングのデモで TDD を紹介していますが、時間がない方は前半の概要と最後のまとめだけでも。(ライブコーディングのデモも非常に学びがあります)
大事なポイントとしては以下ですかね。
- 動作するきれいなコードには2つの道がある
- TDD のサイクル (Red-Green-Refactor)
- テストが予想通り落ちることを確かめる
- 仮実装、三角測量
(ちなみに書籍はこちら > テスト駆動開発)
特に、この 仮実装 や 三角測量 はよく使う手法ですが、TDD に限った話ではないだろうと思います。
例えば、新しいフレームワークやライブラリを試すときに小さいサンプルアプリを作ったりすることがありますが、ゼロからすべてを一気に作るのは難しいので、モックのデータを返したりして、範囲を絞りながら調査を進めると思います。これは TDD の『仮実装』と同じアプローチです。
あと、デバッグするときに、あるパラメータを渡すとこう動作する、別のパラメータを渡すとこう動作する、ということはこのパラメータを渡せばこう動作するだろう、と再現パターンを調べることがあると思います。これは TDD の『三角測量』と同じアプローチです。
おそらく、テスト駆動開発の中で実践している細かいプラクティスは普段からすでにやっていることなのかもしれません。
まとめ
自分も手探りながら テスト駆動開発モドキ を実践してみた中で大事だと考えているのは、テストから考え始めること (テストファースト) です。
テストから考え始めることで、仕様に対してどのように動作するべきか、ということを整理できてシンプルな観点として落とし込めるようになります。テストがシンプルになると、それに対する実装もシンプルになり易いです。これは実践してみて初めて気が付いたことです。
いきなり実装から書き始めるといろいろな条件を1箇所のロジックに詰め込みがちで、あっという間に複雑になります。当然、その実装に対するテストも複雑になります。そして誰もメンテできなくなるわけです。
ちなみに、鑑賞会のあとに参加者で意見交換したところ、やはり気になるのは既存のアプリにテストコードがないときはどうするか、ということ。正直、あとからテストコードを追加するのは非常に難しいと考えています。というか、かけるコストに対して得られるメリットが少ないんではないかと。
こういうときはテストコードは諦めてドキュメントベースでテスト観点を管理する、というのが最近の自分の見解です。
決してテストコードを書くことはマストではないと思います。メンバーのスキルを考慮する必要もあります。大事なのは実装のあるべき姿を最初に整理して何かしらの形で残すことだと思います。もちろんそれが設計の成果物にあたるのかもしれませんが、そのあたりは現場によってさまざまなのかな。
