Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
夏休みはどうだったでしょうか？ 私は、夏休みに入る直前で、かみさんが怪我をして、 夏休み中は、育児や家事に追われて、大変な夏休みでした。
子供が生まれると、生活のリズムも環境も、こんなにすっかり変わってしまうとは思わなかったものです。 まだ慣れなくて、四苦八苦しています。 もっとＸＰを生活の中に取り入れて、効率化を図っていかないと最近は思います。
今回は、私がＸＰ実践の中で、気づかされたことについて書かせて頂いて、 ユニットテストの真のパワー、意義に迫りたいと思います。
１．ファイル名を関数内の固定値に
- ケース：ある設定ファイルを読み込んで、設定パラメータを取得するプログラムを 作った時、 私は、設定ファイル名は一つしかないので、ファイル名を関数の中の固定値にしました。 それまでは、ごく普通の作法でした。
- 問題：しかし、取得パラメータを変えてテストしようとした時に、 ファイル名を固定にすると、ファイルの中身を書き換えて、 テストせざるを得なくなり、全くの手動テストになってしまいました。
- 解決：そこで、ファイル名を引数として渡すようにし、 ファイル名は上位の関数から渡すようにコードを変更しました。 テストパターン用に複数のファイルを作成して、自動テストをできるようにしました。 テストしなければ、全く気がつかなかったことだったと思います。
２．二重ループ
- ケース：２階層のディレクトリ構造から、設定ファイルを検索するプログラムを 作った時、 それまでのＸＰのユニットテストの経験から、 まず、ファイル検索処理を作って、 次に２重ループの処理をかぶせるというふうに、徐々に作成していきました。
- 問題：しかし、そうすることで、ファイル検索処理が埋もれてしまい、 問題が発生した時、ファイル検索処理がおかしいのか、二重ループの処理がおかしいのか 判断が付かなくなってしまいます。 おまけに、ファイル検索処理のユニットテストの意味が薄くなってしまいました。
- 解決：ファイル検索処理を独立した関数にし、 その関数を徹底的にユニットテストすることで、 単独した検索処理も保証できて、 その上に立つ二重ループの処理の基礎をより確かなものにできました。
３．関数は大きすぎ
- ケース：ユニットテスト以前では、自分は関数が小さい方だと思っていました。
- 問題：しかし、ユニットテストをするようになってから、以前のコードを見返すと、 面を食らうほど、大きかったように思います。 人間の脳は、実に柔軟なものだと舌を巻くばかり、意味論として考えた塊は、こんなにも大きくなるなんて。。。 その通りに作成すると、いくつものの要素が一つの関数に詰まってしまいます。
- 解決：ユニットテストするのには、関数の中の要素が一つでないとテストしにくいものです。 要素が多すぎると、数パターンの組み合わせになってしまい、テストの数が多くなり、 入り組んでしまい、複雑になってしまいます。 テストを意識してコーディングすると、関数内の要素と、関数のインターフェース、 関数の互いの構造を考慮するようになり、 一部分をプログラミングする側から、全体を考えるきっかけとなりまます。 そうすることで、ユニットテストが尺度になり、 関数の要素が明確になりコンパクトに、関数の構成が明確になりシンプルに見易くなります。
これらのことから、 私は、 テストするには、テストできるコードを書かないといけないんだということを悟りました。
Ｐ．Ｓ． テストツールで気軽にテストできてこそ、色々とテストする気にさせてくれて、 テストしてみると、色々と気づかせられました。 これが、私の初歩的なＸＰの経験で、一番びっくりし、開発が楽しくて仕方ないと 感じた経験でした。
There is no comment.