4

「TheArtOfUnit Testing」を読んでいて、よくわからない特定の段落があります。

「インターフェースの代わりに基本クラスの使用を避けたい理由の1つは、本番コードの基本クラスに、知ってオーバーライドする必要のある本番依存関係がすでに組み込まれている（そしておそらくある）可能性があるためです。 。これにより、テスト用の派生クラスの実装は、インターフェースを実装するよりも難しくなります。これにより、基盤となる実装が何であるかを正確に把握し、完全に制御できます。」

組み込みの本番依存関係の例を教えてもらえますか？

ありがとう

4

2 に答える 2

4

私のこれの解釈は、基本的に、基礎となる実装を制御できないが、それでもそれに依存しているものです。これは、独自のコードまたはサードパーティのライブラリにある可能性があります。

何かのようなもの：

class MyClass : BaseConfigurationProvider
{
}

abstract class BaseConfigurationProvider
{
    string connectionString;

    protected BaseConfigurationProvider()
    {
        connectionString = GetFromConfiguration();
    }
}

これは、接続文字列が返される場所、おそらく構成ファイルまたはおそらくランダムテキストファイルに依存します-いずれにせよ、の単体テストの外部状態処理は困難MyClassです。

同じことがインターフェースを与えられたのに対して：

class MyClass : IBaseConfigurationProvider
{ 
    string connectionString;

    public MyClass(IBaseConfigurationProvider provider)
    {
        connectionString = provider.GetConnectionString();
    }
}

interface IBaseConfigurationProvider
{
    string GetConnectionString();
}

少なくとも実装を完全に制御できます。インターフェイスを使用すると、単体テスト中に実装のテストバージョンを使用したり、（上記で行ったように）消費クラスに依存性を注入したりできます。このシナリオでは、接続文字列を解決する必要性に依存しています。テストは、異なる文字列または空の文字列を提供できます。

于 2012-07-10T15:20:28.250 に答える
0

one example which i can think of is use of Session variable inside that of asp.net (im a .net guy)
because you have no control over how asp.net populates the session variable you cannot test it simply by making a test case you will have to either override it somehow or make a mock object

and this happens because all the context and cookies arent present when you are testing

于 2012-07-10T15:18:46.753 に答える