やる気がストロングZERO

やる気のストロングスタイル

「テスト駆動開発」を読んでやっとテスト駆動開発ができるようになった

 読んだ。

テスト駆動開発

テスト駆動開発

 

 

ずっとテスト駆動開発をやってみたかったが個人でも業務でも出来ていなかった。

理由としては、
・職場がテスト駆動開発を導入していなかった
・自分も誰もやり方を知らなかった(なんとなく「こういうもんでしょ?」程度の知識しかなかった)

やりたいと思っていたが、具体的にどう進めればよいのかわからず、個人的に何度かトライしてみるもいつのまにかやらなくなって、、の繰り返しを何度かしていた。


xUnitのチュートリアルテスト駆動開発の手順書ではなかった


個人的にテスト駆動開発に取り組んでみようとしたときにまず手をつけたのが、
「xUnitの使い方を調べる」事だった。
チュートリアルをやってある程度使い方がわかったところで、ユニットテストを導入してみるも、それはテスト駆動開発ではなかった。
たしかチュートリアルも「既存のclassに対してテストを追加する」という形で進められていたため、実践でもその順序をなぞった。

実装が完成したあとでテストを書こうとするとうまくテストがかけない構造になっていたり、ついつい次の実装を進めてしまってテストを書き忘れていたりして、いつのまにかまたテストを書かずに実装を進めている状態に逆戻りしていた。

テストを書く強制力が無さすぎて失敗したのだと思う。


テスト駆動開発」はまさにテスト駆動開発の手順書だった


今思えば当たり前だけど「テスト駆動開発」を学びたいと思ったときに調べるのはxUnitの使い方ではなくテスト駆動開発の手法である。
何度も失敗してやっとこの事に気が付きこの本を購入して読んだ。

この本はまさに「テスト駆動開発」で行われる開発を横で見ている以上の経験を体験させてくれた。作業行動の一つ一つに理由と説明を付けてくれている。

テスト駆動開発を行う作業者の脳内を体験できる本だった。


既存の個人プロジェクトにテストを追加しようとした時に効果を体験した

本を読み終えて、まずは既存の個人プロジェクトにテストを追加しようとした。
この個人プロジェクトのコードはviewとロジックがゴチャっとしていたのでリファクタリングしたかったのだが、テストが無いのでまずはテストを追加しようとしていたのだった。

驚いたことに、テストの追加が完了した時、もうviewとロジックはきれいに分離していた。

つまり、テスト駆動開発の流れに沿って
・まずテストしたい機能のテストを書く(まだコンパイルは通らない)
・とりあえずコンパイルが通るように書き換える(まだテストはエラーとなっている)
・とりあえずテストが通るように暫定的に書き換える(テストは通るようになる。実装は仮実装となっている)
・暫定対応を正式対応にする(テスト追加完了)

これらの作業を行うと、自然にロジックが分離した。

テストを追加するには、ロジックがきれいに分離している必要があり、
上記の手順を踏むことで自然にそのように誘導されていったのだった。

 

恐るべきテスト駆動開発

 

テスト駆動開発

テスト駆動開発