4

データベースとやり取りするAPIを使用しています。この API には、要素を照会、ロード、およびデータベースに保存するためのメソッドがあります。新しいインスタンスの作成などを行う統合テストを作成し、そのインスタンスに対してクエリを実行すると、正しいインスタンスが見つかることを確認しました。これで問題ありません。

このコードの単体テストをより高速に実行したいと考えていますが、単体テストの有用性と、実際に何かが得られるかどうか疑問に思っています。たとえば、API を介してある要素を保存するためのクラスがあるとします。これは疑似コードですが、私が使用している API がどのように機能するかを理解してください。

public class ElementSaver
{
    private ITheApi m_api;

    public bool SaveElement(IElement newElement, IElement linkedElement)
    {
        IntPtr elemPtr = m_api.CreateNewElement()
        if (elemPtr==IntPtr.Zero)
        {
            return false;
        }
        if (m_api.SetElementAttribute(elemPtr,newElement.AttributeName,newElement.AttributeValue)==false)
        {
             return false;
        }
        if (m_api.SaveElement(elemPtr)==false)
        {
             return false;
        }

        IntPtr linkedElemPtr = m_api.GetElementById(linkedElement.Id)
        if (linkedElemPtr==IntPtr.Zero)
        {
            return false; 
        }
        if (m_api.LinkElements(elemPtr,linkedElemPtr)==false)
        {
            return false;
        }
        return true;

    }
}

m_api メンバーをモックする単体テストを書く価値はありますか? さまざまな呼び出しのいずれかが失敗した場合に false が返されること、およびさまざまな呼び出しがすべて成功した場合に true が返されることをテストできるようです。さまざまなメソッドが期待されるパラメーターで呼び出されるという期待を設定できますが、これは便利ですか？このコードをリファクタリングして、API のいくつかのわずかに異なるメソッドを使用しても同じ結果が得られるようにすると、テストが中断され、テストを変更する必要があります。このもろさはあまり役に立たないようです。

このようなコードの単体テストを気にするべきですか、それとも私が持っている統合テストに固執するべきですか?

4

2 に答える 2

4

テストがどのようなものかを見てください。入ってくるものがデータベースなどに入るかどうかだけをテストしている場合。自動化された統合テストのみを行うことで、おそらく正しいことをしているでしょう。テストしたいロジックがある場合は、ロジックを単体テストできる個別のクラスと、ロジックを含まないインフラストラクチャ コードの周りのファサードに分解できるかどうかを確認することをお勧めします。

于 2008-12-02T09:51:28.847 に答える
2

次の理由により、私のコードで m_api をモックアウトすることをお勧めします (すべてが疑似コードの例に当てはまるわけではありません)。

  • あなたが述べたように、クラスがエラー処理を適切に実行することを確認できます
  • クラスにもっと複雑なコード (キャッシュなど) がある場合は、モックに期待値を使用して、クラスが適切に動作していることを確認できます。たとえば、同じオブジェクトを 2 回取得しますが、m_api が 1 回だけ呼び出されるようにします。
  • 単体テストでは、適切なデータ セットを作成しなくても動作をテストできます。これにより、m_api の下のデータ モデルが変更されるにつれて、保守性が向上します。
于 2008-12-02T09:48:04.390 に答える