0

私は単体テスト初心者で、リポジトリをテストする良い方法を見つけるのに苦労しています。値をロードする CustomConfigurationManager を作成しましたCustom.Config。しかし、それらをテストする方法がわかりません。

私の質問は

  1. 内部のコードをテストするにはどうすればよいですかGetUserById()
  2. 私のテスト方法CustomConfigurationManager()

これは私がテストしようとしている私のリポジトリです:

public class UserRepository : IUserRepository
{
    public User GetUserById(string id)
    {
        return CustomConfigurationManager.CustomConfig.Users.FirstOrDefault(u => u.UserId == id);
    }
}


public class CustomConfigurationManager
{
    public static Configs CustomConfig
    {
        get
        {
            return CustomConfigLoader.LoadConfig<Configs>();
        }
    }
}

internal sealed class ConfigLoader
{
    public static T LoadConfig<T>() where T : class
    {
        ...

        return LoadFromXML<T>();
    }
}

そしてXML

 <users>
    <user id="Foo" name="Bar" ... />
    ...
</users>

貼り付けたコードは変更されており、実際のコードではありません。これはほんの一例です。

4

1 に答える 1

3

多くの人が、正確な意味で、ファイルを読んでいる場合、それは単体テストではないことを指摘すると確信しています。実際には、そのようなものをもっと緩い方法でテストするか、それを偽造する方法を見つける必要があります。

かなり役立つはずのヒント：

public class UserRepository : IUserRepository
{
    public Configs CustomConfig {get;set;}
    public User GetUserById(string id)
    {
        return CustomConfig.Users.FirstOrDefault(u => u.UserId == id);
    }
}

アイデアは、それを（おそらくコンストラクターでのみ）注入することにより、ファイルから読み取らずにテストできるということです。これは DI (依存性注入) と呼ばれ、一般的にはインターフェイスで行うのが最適です。

CustomConfigurationManager は、プロパティで別の静的メソッドを呼び出すため、テストが困難です。あなたはおそらくそれを使用しないことができます。詳細を隠すだけでなく、依存関係も隠すのは非常に複雑であり、決してやりたくないことです。

InternalsVisibleTo なしで ConfigLoader を実際にテストすることはできませんが、それも悪い習慣だと思います。このクラスは封印する必要がありますか?

可能であれば、特定の実装を想定せずに、メソッドを機能させることに集中して設計してください。あまりにも多くのものを渡していることに気付いた場合は、おそらく新しいクラスが必要です。一度に多くのことを行っていることに気付いた場合は、おそらくより多くのメソッドが必要になります。

于 2013-10-23T20:05:11.253 に答える