13

単体テストを含まない従来の Web アプリケーションを継承しました。いくつか追加したいのですが、どこから始めればよいかわかりません。それらを古いコードに追加する必要がありますか? それとも新しいコードだけですか？そのコードがレガシー コードとやり取りする場合はどうなるでしょうか。何を提案しますか？

4

7 に答える 7

9

まず、今後すべての変更を単体テストすることをお勧めします。ほとんどの人は、これが回帰の良い考えであることに同意すると思います。

ただし、既存のコードの場合、これは、製品にどの程度のリスクを導入するか、許容するかを検討する必要がある状況の 1 つです。問題は、既存のコード ベースの単体テストを開始すると、すぐにリファクタリングと設計改良の多くの機会に気付くことです。

あなたが優れた設計にこだわるが、抜本的なリファクタリングの決定を行う権限を与えられていない場合、古い部分のテストを作成しようとすると失恋するだけです. -- はい、既存のテスト スイートがない場合は、リファクタリングが必要です。本番アプリケーションに大きな影響を与える変更を行うことが許可されていない場合、「ガベージ アダプター パターン」と呼ばれるものを実装することになります。幸運を！

于 2008-12-05T02:06:47.113 に答える
3

Working Effectively with Legacy Codeのコピーを入手することをお勧めします。

私たちは勉強会でこの本を読みました。それは苦痛でしたが、役に立ちました。

トピックは次のとおりです。

  • ソフトウェア変更のメカニズムの理解: 機能の追加、バグの修正、設計の改善、パフォーマンスの最適化
  • レガシ コードをテスト ハーネスに取り込む
  • 新しい問題の発生を防ぐテストを作成する
  • Java、C++、C、および C# の例を含む、任意の言語またはプラットフォームで使用できる手法
  • コードの変更が必要な場所を正確に特定する
  • オブジェクト指向ではないレガシー システムへの対処
  • 構造がないように見えるアプリケーションの処理

これについては、 http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdfで簡単に説明しています。

于 2008-12-05T07:45:48.973 に答える
2

テストのためだけにテストを書くつもりはありません。バグが発見されたとき、または新しい機能を追加するときだけ、テストを書きます。次に、現在の動作を定義するために変更/実装する必要があるコードをボックス化するテストを記述します。バグの場合は、バグが修正されたことを証明するテストを作成します。新しいコードの場合、何をすべきか。次に、修正/新機能を実装します。テストの "ボックス" の外側のコードに触れたくなる場合は、その領域をボックス化するためのテストをさらにいくつか記述します (または、変更を加えるかを再検討してください)。テストへの投資を最大化するために、必要に応じて新しいテストを徐々に導入してください。動作するコードが機能することを証明するテストを作成しても、コードが壊れていることが示されるまでは無意味に思えます。

于 2008-12-05T02:20:55.493 に答える
2

レガシーアプリは階層化されていますか?

その場合は、最初にユニット テストをバックエンド/ビジネス レイヤーに追加します。

そうでない場合は、今後新しいコードに単体テストを追加し、バグが発見された場合 (回帰テスト用)

（最終的に）全体を単体テストする時間/野心がある場合は、機能のリスト（重要なものを最初に）を開始し、それらの単体テストを一度にいくつか追加します

于 2008-12-05T01:56:34.170 に答える
2

継承したコードである場合は、おそらくそれを読み始めて、それが何をし、何をしないのかを理解する必要があります。コード ベースに対する理解の深まりを反映した単体テストを作成することをお勧めします。最終的には、「これらの関数はそれらの実装を持つ関数である」ではなく、「これらの関数はそれらのテストに合格した関数である」というレガシー アプリケーションに関する一連の知識を構築することになります。そうすれば、物事を壊すことなく変更を加える自由と自信が得られます。

于 2008-12-05T02:01:26.577 に答える
1

Web アプリが単体テストされていない場合、おそらく単体テストも容易ではありません。[Unit] テストがないので、単体テストを行うのは危険です。そうです、ニワトリと卵です。さらに、これには時間がかかり、アプリケーションにあまり価値をもたらしません。

アプリケーションのレガシー部分のSelenium、Watir、 HtmlUnit 、または HttpUnit 、 YMMV を使用して、エンドツーエンドの自動テストを作成することを目指しています。これらのテスト (特性化テスト) は、単体テストのように現在のアプリケーションの動作を突き止めますが、外部から、望ましくない副作用を検出する機能を使用して変更を加えることができます。

新しいコードの単体テストを作成し、レガシー コードを変更する場合は、問題の修正または新しい機能の追加を目的とします。

于 2008-12-05T07:01:14.943 に答える
1

アプリケーションの既知の「問題点」でテストを作成します。頻繁に壊れたり、一般的にリスクが高いコードは、この領域で防御の最前線を構築するのに役立ち、そのアプリケーションの単体テストの範囲にチームをさらすのに役立つため、開始するのに適しています。

アプリケーションに対して欠陥が開かれるたびに、今後は単体テストを作成してこの動作を明らかにしてください。修正されたときにお知らせし、将来再び導入されるのを防ぐことができれば幸いです.

さらに、リファクタリングが必要なコードを探します。リファクタリング作業は、単体テストの作成から始める必要があります。これにより、変更を加える前後の両方で機能していることを確認できます。リファクタリングは、最初のうちは困難な場合があります。これは、1 つの破損が予期しない方法でアプリケーション全体に大混乱をもたらす「波及効果」のリスクがあるためです。

于 2008-12-07T15:39:58.247 に答える