3

ユニットテストに関するこの質問は、私を悩ませている別のことを引き起こしました。データベースにアクセスするときに単体テストを実行する3つの方法を行ったり来たりしました。

  1. モックオブジェクトを作成してプラグインします。これにはデータベースが不要であるという利点がありますが、時間がかかり、投資収益率がどれだけ得られるかわかりません。私はIOCとmoqに少し慣れてきましたが、それでも苦痛のようです。
  2. セットアップおよびティアダウンデータベーススクリプトを作成して既知のケースを作成し、それらをテストします。繰り返しになりますが、時間のかかる作業になる可能性がありますが、ほとんどの場合、モックオブジェクトよりも簡単に作成できます。また、ローカルホストにSQLサーバーがあることを前提として、職場の他のユーザーは引き続きそれを実行できます。
  3. devデータベースを手動でチェックし、単体テストを変更します。集中的に手作業ですが、変わらない「テストセット」があれば大丈夫そうです。私のマシンでは、少なくとも:-)。

オプション1が単体テストを行うための「適切な」方法であることは知っていますが、3つのうち、おそらく私が最も使用しなかったオプションです（ただし、最新のプロジェクトはIOCを使用しているため、ドアが開いています）。私はそれの多くが正確に何が嘲笑され、何がテストされているかに依存することを理解していますが、私はここで何が欠けていますか？

コンテキストが役立つ場合、私はC＃ショップにいて、社内アプリケーションを作成していますが、開発者はごくわずかです。

4

4 に答える 4

3

IQueryable<T>ほんの一握りのメソッドを公開するデータアクセス層がある場合、最初のものはそれほど難しくないはずです。偽のデータに使用できる優れたトリックがあります。エンティティオブジェクトをに格納してList<T>を使用するだけAsQueryableです。これは、データ部分のmoqよりも簡単だと思います。

IOCに関しては、私は現在使いすぎているという立場をとっています（私の意見は、この点でプログラマーの少数派を表していることに注意してください）。テスト中にMolesのようなツールを使用して、プログラムの設計を悪用することなくモックを作成できます。デザインで実際に必要とされない限り、IOCは使用しません。

于 2010-06-26T14:04:02.217 に答える
2

私は間違いなく真の単体テスト（オプション1）を使い続けます。これについてのスティーブンのアドバイスが好きです。

また、実際のデータベース（オプション2）との統合テストも使用する必要がある場合があります（オプション2）。なんで？テストする必要があるものの一部（O / Rマッピング、実際のDBスキーマとの互換性など）は、真の単体テストではカバーされていないためです。

セットアップとティアダウンのロジックについては、通常、これから継承するだけで十分です（データベースに.NET、NUnit、およびSqlServerを使用）。

using System.Transactions;
using NUnit.Framework;
namespace Crown.Util.TestUtil
{
    [TestFixture]
    public class PersistenceTestFixture
    {
        public TransactionScope TxScope { get; private set; }

        [SetUp]
        public void SetUp()
        {
            TxScope = new TransactionScope();
        }

        [TearDown]
        public void TearDown()
        {
            if (TxScope != null)
            {
                TxScope.Dispose();
                TxScope = null;
            }
        }
    }
}

やさしい。

于 2010-06-26T14:29:25.573 に答える
1

これには一連の答えがあります。最初に行うことは、テストしている内容を明確に表現することです。それは、背後にデータベース、DAOオブジェクト、データベース構造を持つAPIのファサードですか？

これに到達することは、物事をテストするための最良の方法を決定するのにも役立ちます。あなたがリストしたものに代わるものを私が見ることができるものからもあります。これは、hsqlなどのメモリデータベースで起動し、クラスを実行してそれに対してテストすることです。これは、テストの開始時にデータベース構造を作成できることを意味します。これはメモリ内にあるため、データベースサーバーの使用について心配する必要はなく、高速であり、テストに固有のデータをロードできます。

私はモックをかなり使用しており、クラスの単体テストには最適ですが、そうでない場合もあります。彼らはまた、非常に簡単にリードを逃す可能性があります。モックで機能するものが、統合されたときに機能しないことは珍しくありません。この理由は、モックが表すものから誤って解釈した可能性のある特定の期待と応答をモックにロードしているためです。

誤解しないでください。私はモックが好きで、かなり使用しています。しかしそうすることで、何かがユニットテストされているので、それが正しいと決して思い込まないでください。それはチャンスを増やしますが、統合テストでは実際に100％の保証が得られます。

于 2010-06-26T14:25:50.980 に答える
0

これが難しいと感じさせる実際に何をテストしていますか？

ビジネスレイヤーロジックとサービスレイヤーロジックを永続化コードから切り離すと、DBを使用しなくても、単体テストするコードを簡単に分離できるはずです。

単体テストの最も重要な原則の1つは、分離してテストすることです。その方法を明確に理解していれば、単体テストは簡単です。そうしないと、単体テストが難しくなります。

于 2010-07-02T14:21:22.020 に答える