Think occasionally

本番機で稼動しているプログラムを参考にプログラムを書くことがある。コーディング規準の形に沿っているので、作業がしやすい為である。ただ、ソースをよく読んでいくと、まったく機能していないエラーハンドリングとかをよく見つける。この開発者は本当にテストを実施してきたのだろうかと疑問に思う。これでイイと思って、ロクにテストもしていないことがわかるプログラム程、いやなものはない。

Clean Coder (Chapter5. TDD)

Clean CoderのTDDの3原則はくどく感じたので、自分なりの解釈を記述してみる。

• ソースコードを記述する前に失敗する単体テストケースを記述すること。ソースコｰﾄﾞが完成する直前には、自動化されたテストケースが完成している。(Coverage 90%以上）
• 単体テストケースを記述することは、モジュールの疎結合を目指すことになる。（テストが実施できるソースを開発するようになる為）
• ソースコード完成時に、数分以内に完了するリグレッション・テストが用意可能になる。（変更に対する恐れがなくなる。自動化された単体、受入テストケースが無い場合、結局は大丈夫だと思って実施しないテストケースがでてくるが、その内容が自動化されたテストケースに含まれることになり、より堅牢になる）