1

プライベート メソッドをテストするには、FlexUnit で必要です。describeType を使用してリフレクションを介してこれを行う可能性はありますか、または flexUnit に機能が組み込まれている可能性がありますか? プライベート関数をテストできない人為的な制限は嫌いです。柔軟性が大幅に低下します。はい、プライベート関数をテストするのは良い設計なので、コードをリファクタリングするようにアドバイスしないでください。単体テストのためにカプセル化を解除したくありません。

4

4 に答える 4

6

私はこれが不可能であると99％確信しており、なぜあなたがこれをしたいかを知りたいと思っています。

クラス内で何が起こっているかに関係なく、特定の入力に基づいて、特定のクラスの出力を単体テストする必要があります。期待される出力（単体テストで定義）が変更されない限り、誰かが実装の詳細を変更できるようにする必要があります。

プライベートメソッドをテストする場合、クラスへの変更は単体テストと緊密に結合されます。読みやすさを向上させるためにコードを再シャッフルしたい場合、またはパフォーマンスを向上させるためにいくつかの更新を行いたい場合、クラスが元の設計どおりに機能していても、単体テストを更新する必要があります。

プライベートメソッドをテストすることが有益である可能性があるエッジケースがあると確信していますが、ほとんどの場合、それは必要ないだけだと思います。カプセル化を解除する必要はありません。メソッド呼び出しが正しい出力を提供することをテストするだけです...コードが内部で何をするかに関係なく。

于 2010-05-15T15:08:16.007 に答える
2

「unitTest」というパブリック メソッドを作成し、そのメソッド内ですべてのユニット テストを呼び出すだけです。それらのいずれかが失敗したときにエラーをスローし、テスト フレームワークから呼び出します。

try {
   myobject.unitTest();
} catch (Exception e) {
   //etc.
}
于 2010-06-21T17:54:25.147 に答える
1

そのためには使用できませんdescribeType。

Livedocs - flash.utils パッケージから:

[...]

注: describeType()はパブリック プロパティとメソッドのみを表示し、プライベート、パッケージ内部、またはカスタム名前空間にあるプロパティとメソッドは表示しません。

[...]

于 2010-05-16T07:36:50.623 に答える
0

プライベートメソッドをテストしたいという衝動がたまらないときは、メソッドのテスト可能な名前空間を作成するだけです。

次のようなファイルで名前空間を宣言します。

package be.xeno.namespaces
{
    public namespace testable = "http://www.xeno.be/2015/testable";
}

次に、次のように、テストするメソッドのカスタムアクセス修飾子としてtestableを使用できます。

public class Thing1
{
    use namespace testable;

    public function Thing1()
    {
    }

    testable function testMe() : void
    {

    }
}

次に、テストで名前空間を使用して、その修飾子にアクセスできます。

public class Thing2
{
    use namespace testable;

    public function Thing2()
    {
        var otherThing : Thing1 = new Thing1();
        otherThing.testMe();
    }
}

実際、これは機能を別のクラスに分割する必要があるというヒントだと思います。

于 2011-05-07T02:45:34.320 に答える