問題タブ [semantic-comparison]

次のようなテストを作成しました。このテストでは、Equal-classのen-overloadを作成している必要がありCodeTableItemます。

テストは正常に機能しますが、残念ながらEquality-functionに依存しています。つまり、CodeTableItem-classをもう1つのフィールドで拡張し、-functionを拡張するのを忘れたEquals場合、すべてのフィールドをテストするわけではありませんが、単体テストは引き続き緑色で実行されます。 。テストに準拠するためだけに作成されたこのEquality汚染（テスト固有の同等性を参照）を回避したいと考えています。

を使用してみOfLikenessましたが、次のようにテストを書き直しました。

しかし、Capacityが等しくないため、テストは失敗します。リフレクションを何度も実行するコードを作成しましたが、通常、フィールドを無視するためのオーバーロードを実装することになりました。またはで特定のフィールドを無視する方法はありますOfLikenessかShouldEqual？または、この問題を解決する他の方法はありますか？

単純なクラスの2つのインスタンスを使用するCreateProxy()機能の使用方法を理解しようとしています。Likeness<T>()

次のテストでは、2つの文字列プロパティの値を持つインスタンスにaを使用FixtureしCreate<T>ますBand。

私はさまざまなアサーションを試しましたが、問題の核心は、CreateProxyメソッドがのプロパティを設定していないことであるようです。そのため、同じプロパティ値を持つのBand2つのインスタンスを比較しようとしても、メソッドのインスタンスは常にnull値があります。BandCreateProxy

私は何か間違ったことをしなければなりませんが、PloehブログとSOで見つけることができるすべてを読みました、そして私がしていることと比較するのに十分に単純な例を見つけることができません。何か案は？

Autofixture のCreateProxy メソッド に関する以前の質問で、潜在的なバグが特定されました。

この失敗したテストはその結果ではないと思いますが、むしろ Likeness.Without(...).CreateProxy() 構文がどのように機能するかについての私の継続的な混乱です。オブジェクトの新しいインスタンスを作成し、その作成がSUTであると見なして、元のテスト を少しだけ複雑にする次の失敗したテストを考えてみましょう。

ここにバンドがあります：

私の以前の質問Sourceは、 が一般的にどうあるLikenessべきかを理解するのに役立つほど複雑ではありませんでした。

ソースはSUTの出力である必要がありますか? その場合、AutoFixture によって作成されたテンプレートインスタンスと比較されますか?

または、ソースはAutoFixture によって作成されたテンプレートインスタンスである必要があります。その場合、 SUTの出力と比較されますか?

編集：テストのエラーを修正

プロパティをと新しいインスタンスのtemplate.Brassプロパティの両方に誤って割り当てたことに気付きました。更新されたテストは修正を反映しており、6 つのアサーションすべてがパスするようになりました。Brass StringsBandvar createdBand = new Band {Brass = template.Brass, Strings = template.Strings}

Given these classes:

Why does this test pass...

...and this one fail? (the difference is the DrumAndBaseBand instantiation)

Ploeh.SemanticComparisonマッピング プロセスのLikeness意図した出力を効果的に表現する方法としてを使用しています ( PluralSight に関する Mark Seemann の優れた Advanced Unit Testing コースで説明されているように)。

一部のデータが正しくマッピングされていることをテストしています。これは次のようになります。

しかし、私は満足していません:-

1. Resemblance に名前を付けたい (つまり、.Without( y => y.ProgrammaticIdentifier)カスタマイズに名前を付ける)
2. との対称性が失われましたAssert.Equal( expected,actual, comparer)(ただし、 からのエラー メッセージは確実に必要ですShouldEqual) 。

表現された制約内でこれを表現するよりクリーンな方法はありますか?

同じ型の 2 つのオブジェクトをメンバーごとに比較する必要がある単体テストを作成しています。私は SemanticComparison ライブラリを使用して、カスタム比較コードを記述せずにこのタスクを処理することにしました。フラットオブジェクトを比較するときに非常にうまく機能します。オブジェクトにネストされたオブジェクトが含まれている場合、メンバーごとに比較する必要がある場合に問題があります。

内部オブジェクトはメンバーごとではなく参照によって比較されるため、これは機能しません。

それを機能させるには、ネストされたオブジェクトのプロキシを作成して、デフォルトの equals 実装をオーバーライドする必要がありました。

正しく動作しますが、サービス コードのリファクタリングを行った後、Inner クラスの value プロパティが期待値と異なるバグが発生したとします。SemanticComparison の優れた機能は、不平等の原因となったメンバーの名前をログに記録できることです。ただし、この場合、Inner クラスの特定のプロパティの名前ではなく、"Inner" のみが不一致として返されます。

何か不足していますか？実際の不一致メンバーを返すことができるように構成することは可能ですか?

これは明らかに、この例のような単純なデータ構造では問題になりませんが、実際のコードをテストするには不便になる可能性があります。

AutoFixture SemanticComparison で、オブジェクトの指定されたプロパティまたは指定された型に対してカスタム比較子を設定することは可能ですか?

たとえば、DateTime 型のプロパティを持つオブジェクトを比較する必要があります。Likenes を使用してそれらを比較したいが、ミリ秒レベルの違いを破棄する比較の精度が必要です (データベースから DateTime を取得した後に精度が失われた可能性があります)。