7

より複雑な単体テストでは、多くの場合、特定のルール セットが存在する必要があります。これらのルールの一部には、別のルールへの依存関係があります。順序が関係するので、そのために RuleChains を使用します。これまでのところすべて順調です。

ただし、これはほとんどのテストで繰り返されます (追加のルールが使用されることもあります)。この重複は不要であり、繰り返すのが面倒であるだけでなく、追加のルールを統合する必要がある場合、多くの場所で調整する必要があります。

私が持ちたいのはRule of Rules、つまり、他の (アプリケーションとテスト固有の) ルールを含むか集約する (定義済みの) ルールです。

これが現在どのように見えるかの例を示します。

public LoggingRule logRule = new LogRule();
public ConfigurationRule configurationRule = new ConfigurationRule();
public DatabaseConnectionRule dbRule = new DatabaseConnectionRule();
public ApplicationSpecificRule appRule = new ApplicationSpecificRule();

@Rule
RuleChain chain = RuleChain.outerRule(logRule)
                           .around(configurationRule)
                           .around(dbRule)
                           .around(appRule);

与えられたルールが相互に依存していると仮定します。例えば、ApplicationSpecificRule は、接続を確立するために DatabaseConnectionRule が最初に実行されることを要求し、ConfigurationRule は空の構成を初期化しているなどです。また、この (かなり複雑なテスト) では、すべてのルールが実際に必要です。

これまでに思いついた唯一の解決策は、定義済みの RuleChain を返すファクトリ メソッドを作成することです。

public class ApplicationSpecificRule extends ExternalResource
{
    public static RuleChain basicSet()
    {
         return RuleChain.outerRule(new LogRule())
                         .around(new ConfigurationRule())
                         .around(new DatabaseConnectionRule())
                         .around(new ApplicationSpecificRule());
    }
}

テストでは、これを次のように使用できます。

@Rule
RuleChain chain = ApplicationSpecificRule.basicSet();

これにより、重複が解消され、追加のルールを簡単に統合できます。その RuleChain にテスト固有のルールを追加することもできます。ApplicationSpecificRuleただし、追加のセットアップに必要な場合は、含まれているルールにアクセスできません (ドメイン オブジェクトを作成するためにが必要であると仮定します)。

理想的には、これを拡張して、ルールadvandancedSetの上に構築されるなど、他の定義済みセットの使用もサポートするようにします。basicSet

これはどういうわけか単純化できますか?そもそもそれは良い考えですか、それともルールを誤用しているのでしょうか? テストを再構築するのに役立ちますか? 考え?

4

2 に答える 2