テスト駆動開発は、２つのシンプルなルールを守って開発をすれば良いだけですが、意外とやり切るのが難しい。やり切るのが難しいけど、テスト駆動開発はやっていきたいと考えています。
- 自動化されたテストが失敗した時のみ、新しいコードを書く
- 重複を除去する
参考になる書籍は下記。
何冊かテスト関連の書籍は読んではいるのですが、テスト駆動開発をやりきるのは難しいと考えています。開発に参加する人全員が意識してテストを継続的に実装していく必要がありますし、大きな仕様変更があったときの影響範囲が大きくて継続が難しくなることもあります。
Webアプリだと特にサーバーサイド、フロントエンドとでテストが必要で、それぞれ使うプログラミング言語がちがったり、よく使われているテスト用パッケージの種類がちがったり、といったことも多くあります。
そういった開発では、最初にテストができる環境を用意して、そこから開発を進めるというのは、そこそこの負担があって、なかなか難しいところがありますが、そこを避けているとスタートが切れないので、頑張って用意する必要があると考えています。
まぁ、環境を用意するのに頑張らないといけない、という時点でよろしくないわけですが、慣れてくると頑張らなくてもできるようになるのかなぁ、とも考えていて、何事も経験だよな、という感じです。
さて、テスト駆動はプログラムの仕様をテストコードで記述してから実装をするという視点からすると、是非やるべきなのですが、どこまで仕様を書く必要があるのかということも考える必要があって、そのあたりが大変な感じもしています。まぁ、プログラムが対象とするドメインのモデルの正確な表現をどこまで決めておくか、といったあたりが難しいはずです。最初のうちは、そこそこ細かいところまで書いていても、時間が足りなくなってくると大雑把になりがちだという。
大雑把な仕様をテストとして先に書けると良いのですが、Webアプリだと統合テストの仕様となってしまいがちで、そういうテストはなかなか難しいところがあります。APIの仕様を先に作って、そちらとフロントエンドは分離して仕様を決めてテストできるようにしていくのが良いと考えています。
そういった意味では、必要なプログラムはパッケージ化してどんどん分割して、仕様（テスト）もパッケージ単位で用意できるようになると、何かと楽なのかもしれません。パッケージ化もそこそこ面倒ですけどね…
テスト駆動開発ではTODOリストを作って、仕様を明確にしつつ開発を進めることができそうなので、それが自然とできるようにはなりたいと考えています。
まとまりのない文章ですが、まぁ、こんな感想を持ったということで記録として残しておきます。さぁ、レッツ、レッド、グリーン、リファクタリング！