私たちのチームは、レガシーコードベースのモジュールのいくつかを再調整する予定です.Javaで書かれたWebアプリケーションです。ユニットテストは全くありません。レガシーコードの品質保証はリファクタリングされています
リファクタリングを行う前に、既存の機能のjunitを書くようにデベロッパーに依頼しましたが、それほど広範ではないと確信しています。
リファクタリングが既存の機能を妨げないようにするために、他の対策（ブラックボックス/ホワイトボックス/プロセス）を教えてください。
現在のシステムはかなり安定しており、8年以上実行されています。
おかげでより多くのjunitsを書く以外に グレー
、あなたは可能性が常にrecord test scripts with JMeter. はあなたが期待する結果を取得していることを確認するアサーションを含めます。
2つの問題に直面する可能性があります。つまり、コードが現代的な意味で単体テスト可能ではなく、まだ捕捉されていないコード内にバグがあることです。このような状況に直面したら、可能な限り多くの白黒ボックステストを使用することを強くお勧めします。これはわかりますが、痛いプロセスですが、それを緩和する方法があります。
エンジニアはいくつかのインターフェイスを除外して、いくつかの統合テストを作成できますか。つまり、リファクタリングであれば、いくつかの共通領域で固められ、アプリケーションを複数の小さなチャンクに分割することができます。そうすれば、より多くのテストを実行するための、より大きな手段が得られます。それはまた、あなたが期待するもののために既存のコードを相互参照することを可能にします。
あなたは正しいです。ほとんどのコードは単体テスト可能ではありません。リファクタリングの中には、ほとんどが未使用の変数やメソッドを取り除き、繰り返しコードを共通のメソッドに入れているものがあります。私たちは、方法と変数が本当に使われていないことをツールで確かめています。そして、ユニットテストができないブラックボックステストでカバーしています。 –
@Jengaブロックは注意してください。レガシーコードでは、間違った場所に「バグ修正」があることがあります。ロジックは、別の場所にあるバグのあるロジックに直接関連する1か所にあります。バグを修正することで、別のバグを導入する可能性があります。 – wheaties
マイケルフェザーズのWorking Effectively with Legacy Codeを読んでから、始めてください。
おそらく、現在の状態のコードは（おそらく単位ではないので）有効にユニットテストすることはできません。私がうまく動作していることは、単純な合理的な入力で実行して出力を記録する統合レベルのテストです。 Webアプリケーションはこれを特に適切にします。それらを記述してから、少数のメソッドとクラスを作り出してください。これらの新しいテストでは、すべての新しいユニットをテストしています。それは最初からTDDを行うよりも多くの作業ですが、確かに実行可能です。
これはコード管理に関する全く新しい（より楽観的な）見通しを私に与えた素晴らしい本です。 – nont
本を提案してくれてありがとう。私はそれを通って有用であることを発見しています。私は開発者にテストをwirteし、それを修正するよう依頼しました。しかし、時間/予算の制約を受けている攪拌TDDにはいくつかの妥協点があるだろう。 –
ねえ、これは良いアイデアです。しかし、プロジェクトは私が現在のリリースに投資することができないほど大きく動いています。私は将来のリファクタリングイニシアチブでこのアプローチを使用することができます。ありがとう。 –