まずは単体テストから！

久しぶりに単体テストコードを書いてます。
既存のシステムの移植作業なのですが、
単体テストが無かったので作成しています。
ただ、解析するよりも単体テストを作成する方が理解も深まりますしね！

改めて、つくづくと、単体テストコードはソフト開発には欠かせないと感じます。

そう感じる事をつらつらと。

1)正しいコードに集中出来る
　環境(ハードやOS、etc）的な制約が無く、正しい論理を書く事に集中できる。
　もちろん、処理としては環境依存するものは存在しますが、
　これは設計でカバーすべき。
　結果的に、正しいコード（論理）を書く事に集中出来る。

2)不具合原因の特定が早い
　単体テストにパスしている論理を疑う必要がなくなるので、
　結果的に疑うべき範囲が狭くなり、原因の特定が早くなる。

3)再現可能
　単体テスト環境でほとんどの不具合が再現可能かと思っています。
　実機でしか起きない不具合は極々僅かかと。
　多少の制約や条件はあるにしても、
　すべて論理ですから、単体テストで再現可能になる筈

4)リファクタリングすべきところが分かる
　テストがし難いところは関係性が複雑だったり
　依存関係が強すぎる事が明確となります。
　つまり、それはリファクタリング対象となります。

5)動くドキュメント
　全体の概念図や構成図はドキュメント化が必要ですが、
　詳細な論理は細かなシーケンスを書くよりも
　単体テストを動くドキュメントとすれば十分かと。
　開発者にとっては十分過ぎるドキュメントかと思います。
　シーケンス図は設計作業としては必要かと思います。
　また、イメージとして記憶するのにも役に立ちます。
　ただ、あれもこれもメンテナンスするのは大変なので、
　単体テストだけをメンテナンスすれば良いと思うのです。

6)正しいコードに集中出来る（デバッグ時）
　今回、ある環境で動かすと発生する不具合を
　単体テストを活用して原因特定したのですが、
　関連した単体テストでパスしているテストがあるので、
　正しく動く条件は分かります。
　あとは、その条件をどのように壊すか、
　壊す組み合わせを考えれば良い事になります。
　それ以外は考える必要がなくなります。
　ハード的な要因を疑うよりも、論理に集中する事で、
　原因究明が早くなります。

と、長くなるので、このへんで。
やはり、単体テストが中心の開発が欠かせないですね！
それは、ずばりリボンモデルです！！