2

初めてのイベント中心のプロジェクト (CQRS、イベント ソーシングなど) に TDD を適用し、Greg Young の単純なテスト フレームワーク Given, When, Expect に従ってテストを作成しています。私のテスト フィクスチャは、コマンド、コマンド ハンドラ、および集約ルートを受け取り、出力されたイベントをテストします。

CommandTestFixture<TCommand, TCommandHandler, TAggregateRoot>

たとえば、ここに典型的なテストがあります

[TestFixture]
public class When_moving_a_group : 
     CommandTestFixture<MoveGroup, MoveGroupHandler, Foo>

全体としてこれらのテストには非常に満足していますが、上記のテストで問題が発生しました。集約ルートには、グループのコレクションが含まれています。このコマンドMoveGroupは、from & to インデックスを取得して、コレクションを並べ替えます。テストをセットアップし、正しいGroupMovedイベントが正しいデータで生成されたことを確認しました。

追加のテストとして、Groups コレクションの並べ替えが実際に正しく行われたことを確認する必要がありますか? 集約ルートに公開ゲッター/セッターがない場合、これを行うにはどうすればよいですか。特定のインデックスでグループを取得するメソッドを追加することはできますが、このカプセル化の解除は単にテスト可能にするためではありませんか?

これについて正しい方法は何ですか？

編集

グループの並べ替えは、集約ルートの GroupMoved ハンドラーで行われます。

private void Apply(GroupMoved e)
{
    var moved = groups[e.From];
    groups.RemoveAt(e.From);
    groups.Insert(e.To, moved);
}
4

1 に答える 1

1

ここで摩擦が生じるのは、内部実装について何かを主張したいからですが、手元にあるのは最上位レベルにあります。

テストとアサーションは、同じ論理レベルにある必要があります。これを再配置するには、次の 2 つの方法があります。

グループの並べ替えは、最上位にある後続のコマンドまたはクエリにどのような影響を与えますか?

これにより、グループの順序について直接何も主張しなくても、正しい結果が得られると主張する手段が得られるはずです。これにより、テストが最上位に保持され、あらゆる種類の内部リファクタリングが可能になります (たとえば、グループの遅延ソートなど)。

より低いレベルでテストできますか?

上記のテストが複雑すぎると思われる場合は、テストをより詳細なレベルで構成することをお勧めします。これは、細部のセクションに焦点を合わせて正しくするようなものだと思います。

このレベル (複合ルートではなく) では、インターフェイスはグループについて認識し、アサートしたいものをアサートする機会があります。

または、このテストが必要ですか?

上記のいずれかのレベルで適切なテストが見つからない場合、このテストが本当に必要ですか? 目に見える外見上の違いがない場合は、テストで動作を固定する必要はありません。

于 2012-04-09T00:57:28.363 に答える