11

junit で drools ルールをテストするためのベスト プラクティスは何ですか?

これまでは、ルールをテストするために dbunit で junit を使用していました。hsqldb に入れられたサンプル データがありました。いくつかのルール パッケージがありましたが、プロジェクトの終わりまでに、特定のルールをテストし、他のルールを起動しないようにするための適切なテスト入力を作成することは非常に困難です。

したがって、正確な問題は、junit でのテストをテスト用の 1 つ以上の特定のルールに制限するにはどうすればよいかということです。

4

5 に答える 5

7

個人的には単体テストを使用して、分離されたルールをテストします。分離されたルールが機能しているために知識ベースが機能しているという誤った安心感に陥らない限り、それほど悪いことはないと思います。知識ベース全体をテストすることはより重要です。

AgendaFilterと StatelessSessionを使用して分離テストを作成できます

StatelessSession session = ruleBase.newStatelessSesssion();

session.setAgendaFilter( new RuleNameMatches("<regexp to your rule name here>") );

List data = new ArrayList();
... // create your test data here (probably built from some external file)

StatelessSessionResult result == session.executeWithResults( data );

// check your results here.

コードソース: http://blog.athico.com/2007/07/my-rules-dont-work-as-expected-what-c​​an.html

于 2010-10-11T08:57:52.733 に答える
5

Drools の単体テストを作成するのに役立つ単純なライブラリを作成しました。機能の 1 つはまさに必要なものです。ユニット テストに使用する特定の drl ファイルを宣言します。

@RunWith(DroolsJUnitRunner.class)
@DroolsFiles(value = "helloworld.drl", location = "/drl/")
public class AppTest {

    @DroolsSession
    StatefulSession session;

    @Test
    public void should_set_discount() {
        Purchase purchase = new Purchase(new Customer(17));

        session.insert(purchase);
        session.fireAllRules();

        assertTrue(purchase.getTicket().hasDiscount());
    }
}

詳細については、ブログ投稿をご覧ください: https://web.archive.org/web/20140612080518/http://maciejwalkowiak.pl/blog/2013/11/24/jboss-drools-unit-testing-with- junit-よだれ/

于 2013-11-26T10:14:26.663 に答える
5

テストでルールの実行を 1 つのルールに制限しようとしないでください。OO クラスとは異なり、単一のルールは他のルールから独立していないため、単体テストを使用して単一のクラスをテストするのと同じ方法で、ルールを分離してテストすることは意味がありません。つまり、1 つのルールをテストするには、他のルールと組み合わせて適切な効果があるかどうかをテストします。

代わりに、すべてのルールで少量のデータを使用してテストを実行します。つまり、ルール セッションで最小数のファクトを使用してテストを実行し、結果をテストして、特定のルールが実行されたことを確認します。最小限のテスト データ セットでは 1 つまたは 2 つのルールしかアクティブにできないため、実際の結果は、考えているものとそれほど違いはありません。

サンプル データについては、静的データを使用し、テストごとに最小限のテスト データを定義することを好みます。これにはさまざまな方法がありますが、Java でファクト オブジェクトをプログラムで作成するだけで十分な場合があります。

于 2010-10-06T07:58:20.157 に答える
4

DBUnit を使用した単体テストは実際には機能しません。DBUnit との統合テストは行います。理由は次のとおりです。 - 単体テストは高速である必要があります。-- DBUnit データベースの復元が遅い。簡単に30秒かかります。-- 実際のアプリケーションには、null 以外の列が多数あります。そのため、単一の機能用に分離されたデータでも、データベースのテーブルの半分を簡単に使用できます。- 単体テストは分離する必要があります。-- テストごとに dbunit データベースを復元して分離を維持することには欠点があります。 --- すべてのテストを実行するには数時間かかります (特にアプリケーションが大きくなるにつれて)。はテストではないため、アプリケーションはバグだらけです。--- 単体テストごとにデータベースの半分を作成するのは、多くの作成作業と多くのメンテナンス作業が必要であり、簡単に無効になる可能性があります (検証に関しては、どのデータベース スキーマが行っていないか)

代わりに、DBunit を使用して統合テストを記述します。 - 1 つの DBunit、すべてのテストで同じ。ロードは 1 回だけです (500 回のテストを実行したとしても)。-- 各テストをトランザクションでラップし、各テスト後にデータベースをロールバックします。とにかく、ほとんどのメソッドは必要な伝播を使用します。伝搬が requires_new の場合にのみ、テストデータをダーティ オンリーに設定します (次のテストがある場合に次のテストでリセットするため)。- そのデータベースにコーナー ケースを入力します。ビジネス ルールをテストするために厳密に必要とされるよりも多くの一般的なケースを追加しないでください。通常、一般的なケースは 2 つだけです (「1 対多」でテストできるようにするため)。- 将来性のあるテストを書く: -- アクティブ化されたルールの数または挿入されたファクトの数をテストしないでください。-- 代わりに、特定の挿入されたファクトが結果に存在するかどうかをテストします。

于 2010-10-11T08:56:09.350 に答える
0

単体テストとは、最小限のコードを取り、仕様を定義するすべての可能なユースケースをテストすることです。統合テストの目的は、考えられるすべてのユースケースではなく、連携して動作する複数のユニットの統合です。ルールについても同じことを行います。ビジネスの意味と目的によってルールを分離します。最も単純な「テスト対象のユニット」は、共通の DSL 定義ファイルやデシジョン テーブルなど、単一または高度にまとまりのあるルール セットと、それが機能するために必要なもの (存在する場合) を含むファイルです。統合テストでは、システムの意味のあるサブセットまたはすべてのルールを使用できます。

このアプローチでは、一般的なシナリオを再現してテストするために、多くの分離された単体テストと、限られた量の一般的な入力データを使用したいくつかの統合テストを用意します。新しいルールを追加しても、ほとんどの単体テストには影響しませんが、統合テストはほとんどなく、新しいルールが一般的なデータ フローにどのように影響するかが反映されます。

このアプローチに適したJUnitテスト ライブラリを検討してください

于 2015-02-25T15:24:47.850 に答える