最近、すべてのコードに単体テストがあるわけではない古いシステムでいくつかのコードを変更する必要がありました。
変更を加える前にテストを書いておきたいが、各クラスは多くの依存関係やその他のパターンを作成してテストを非常に難しくした。
明らかに、テストを簡単にし、テストを書いてから変更するために、コードをリファクタリングしたかったのです。
これはあなたのやり方ですか？あるいは、リファクタリングが完了した後にほとんど削除される難しいテストを書くのに多くの時間を費やしますか？テストされていないコードとテストできないコードはどのようにテスト/変更しますか？
まず、here's a great article with tips on unit testing。第二に、私は古いコードの変更のトンを作ることを避けるための素晴らしい方法が、あなたがそれをテストすることができるまで少しリファクタリングすることであることを発見しました。これを行う簡単な方法の1つは、プライベートメンバーを保護し、保護されたフィールドをオーバーライドすることです。
たとえば、コンストラクタ中にデータベースからいくつかのものを読み込むクラスがあるとします。この場合、保護されたメソッドをオーバーライドすることはできませんが、保護されたフィールドにDBロジックを抽出し、テストでそれを上書きすることができます。
public class MyClass {
public MyClass() {
// undesirable DB logic
}
}
は
public class MyClass {
public MyClass() {
loadFromDB();
}
protected void loadFromDB() {
// undesirable DB logic
}
}
となり、その後、あなたのテストは次のようなものになります：あなたはこのような場合にはDBUnitのを使用することができますので、これは、やや悪い例のある
public class MyClassTest {
public void testSomething() {
MyClass myClass = new MyClassWrapper();
// test it
}
private static class MyClassWrapper extends MyClass {
@Override
protected void loadFromDB() {
// some mock logic
}
}
}
を、私私はロードされているデータとはまったく関係のないいくつかの機能をテストしたかったので、最近、同様のケースでこれを実際に行ったので、非常に効果的でした。私はまた、メンバーのこのような公開が、他の同様のケースで有用であることを発見しました。これは、長い間クラスにあった依存関係を取り除く必要があります。
フレームワークを作成している場合は、実際にフレームワークのメンバーにメンバーを公開しても構わない限り、このソリューションを使用することをお勧めします。
これは少しハックですが、私はそれが非常に有用であることを発見しました。
リファクタリングが完了すると、単体テストが削除される理由がわかりません。実際には、ユニットテストスイートはメインビルド後に実行する必要があります（別の "テスト"ビルドを作成することができます。これは主製品のビルド後にユニットテストを実行するだけです）。そうすれば、他のサブシステムのテストが破損しているかどうかがすぐにわかります。ビルド中にテストを実行するのとは少し違うことに注意してください。いくつかの制限されたテストはビルド中には便利ですが、通常、ユニットテストが失敗するだけでビルドを "クラッシュ"させるのは非生産的です。
Java（チャンス）を書く場合は、http://www.easymock.org/をチェックしてください - テスト目的のカップリングを減らすのに役立ちます。
@valters
私はテストビルドを壊すべきではありませんあなたの声明に反対。テストは、テストされた機能に対して新しいバグが導入されていないことを示すものでなければなりません（見つかったバグは、テストが見つからないことを示すものです）。
テストでビルドが中断されない場合は、新しいコードでビルドが中断され、テストでカバーされていてもしばらくの間知られていない状況に簡単に入り込むことができます。失敗したテストは、テストまたはコードのいずれかを修正する必要がある赤い旗でなければなりません。
さらに、テストでビルドを破らないようにすると、失敗率がゆっくりと上がり、信頼性の高い回帰テストがなくなります。
テストで問題が頻繁に発生する場合は、テストが非常に壊れやすい方法で記述されている可能性があります（DB単位を正しく使用しないデータベースなど、変更可能なリソースに依存するか、外部のWebサービスを擬似すべきである）、テストに適切な注意を払わない開発者がチーム内に存在することを示す可能性があります。
ASAPをコンパイルできないコードを修正するのと同じように、失敗したテストはできるだけ早く修正する必要があると確信しています。
「従来のコードで効果的に作業する」を読んだことがあります。「テストできない」コードの処理には非常に便利です。
いくつかの手法はコンパイルされた言語にしか当てはまりませんが（私は「古い」PHPアプリケーションに取り組んでいます）、ほとんどの本はどの言語にも当てはまります。
リファクタリングの書籍では、リファクタリング前にコードが準理想的な状態または「メンテナンス対応」状態にあると想定されることがありますが、私が扱っているシステムは理想的ではなく、いくつかの技術が使用されています（私は最初の開発者を非難していませんが、私はそれらの1つです）ので、テストは一切ありません。この本はこの種の状況に対処していますが、他のリファクタリングの本は通常そうではありません（この程度ではありません）。
私は編集者からもこの本の著者も受け取っていないことを言及する必要がありますが、リソースは従来のコードの分野では欠けているので、フランス語、それは別の話です）。