2
我々は典型的なリポジトリにMSTestをを使用して正しい方法
public class Repository:IRepository<Entity>
{
public Entity GetById(int id)
{
//blah
}
public IEnumerable<Entity> All()
{
//blah
}
public void Insert(Entity entity)
{
}
public void Update(Entity entity)
{
//blah
}
public void Delete(Entity entity)
{
//blah
}
}
があると、私は、エンティティを挿入、更新するリポジトリの能力をテストしたいです。具体的なリポジトリとしてすぐに、私は実際のDBに対してテストしています。だから、
、私は挿入メソッドをテストする - 戦略は
- 明らかなのは、
- アサートエンティティがリポジトリ
しかし、私がUpdateメソッドのテストを考えているとき、それはやや面倒です。 主な質問は、DBを確保するために、どのように
- ですが、すでに私が更新する をフェッチして試すことができ、オブジェクトが格納されていますか？
- 空のデータベースに対して更新をテストするにはどうすればよいですか？
回避策のように見えるのは、不要なコードとテストが膨らんでしまうためです。 優雅な解決策はありますか？
あなたは分離されたユニットをテストしているのではなく、複数のユニットを統合しているので、 'unittest'は本当に単体テストではありません。あなたがしたいことを考え直す。コードの単体テストを行う場合は、更新メソッドのみをテストします。更新メソッドが目的のパスに従っているかどうかをテストし、そのインスタンスを意図した状態にしておくことで、これを行うことができます。 – Polity
そして、RDBMSを扱う私のリポジトリクラスを単体テストする適切な方法は何ですか？どういうわけか私はそれが何をすべきかを確認する必要があります。 –
この方法で試してみてください：更新メソッドを単体テストする必要があります。データベースに障害が発生した場合（たとえばdiskspaceがいっぱいの場合）、更新方法が間違っているか、壊れているとは限りません。アイテムがデータベースで更新されたかどうかは、テストする必要はありません。更新方法が期待したとおりに行われたかどうかを確認する必要があります。 （例えば、データベース層に適切な呼び出しを行います） – Polity