 |
||||||||||||
|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| はじめに | ||||||||||||
|
ソフトウェアにおいてバグはつきものです。1人のプログラマが一度に書けるバグのないコードは最大で数十ステップといわれています。当然、業務システムは数万から数十万ステップにもなるわけですから、バグは存在していて当然です。 そしてバグは、できるだけ早く見つけるに越したことはありません。早期に発見できたバグは、問題の追及が比較的楽になるからです。逆にかなり前から潜んでいたバグは、考慮すべきソースコードの範囲が広くなるために問題の追及が困難になってしまいます。 そこでXP（eXtreme Programming）などのアジャイル開発プロセスでは、常時結合（Continuous integration）というプラクティスが提唱されています。 これは、「最新のソースコードを常に自動テストし、常に動作するソースコードを入手できる状態にしておく」ことです。これにより開発の早い段階からバグを発見することができるため、品質が向上します。 またバグは、開発フェーズだけに存在している訳ではありません。本番運用後にも突如として発生するものです。そのため、保守フェーズにもテストは必要です。常時結合を考えると、つい開発フェーズだけに目を向けがちですが、保守フェーズまでも含めたテストの枠組みを考えておく必要があります。 というわけで本連載「チーム開発ここまできた、個人からチームの生産性向上へ」の最終回は、Visual Studio 2005 Team Foundation Server（VS2005 TFS）の自動ビルドによるプログラムの品質および保守面での有効性について考察していきます。 |
||||||||||||
| 常時結合しないときの問題 | ||||||||||||
|
Visual Studio 2005以前でもテストの自動化は行っていました。例えば、テスト自動化のためのツールであるNUnitを使い、テストプログラムを記述してきました。 しかしテストの自動化までは行っても、テストの実行を自動化する（常時結合）まで行っているプロジェクトそれほど多くはないと思います。そして、常時結合を行わない場合、次のような問題が発生する可能性があると考えます。 例えばプログラマは開発フェーズにおいて、とにかく自分の担当分の単体テストと実装が完了し、報告できればよいと考えます。ですから、テストプログラムで環境に依存するコードを記述していても気にしません。つまりデバッグ用のログを特定のドライブに出力するようにソースコードを記述するハードコードのような場合です。 このような場合、本番後に発生した問題の修正後、リグレッションテストのためにすべてのテストを実行しても、テストが動作しないことがあります。 環境依存しているテストプログラムの問題は保守フェーズに表面化するわけですから、開発フェーズの時にはそのプログラムに問題があるとは気づきにくくなります。 往々にしてプロジェクトの初期フェーズにおいては、開発チームの意見が取り入れられがちです。というのも、とりわけモジュールが完成することに注力しているからです。 そのためプロジェクトの立ち上げ段階で、「常時結合までは不要である」と判断されることが多いです。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
