問題タブ [tdd]

テスト駆動開発を実践する初心者として、私はしばしば、データベースへの永続性を単体テストする方法について困惑することになります。

技術的にはこれが統合テスト (単体テストではない) になることはわかっていますが、次の最適な戦略を見つけたいと考えています。

1. クエリのテスト。
2. インサートのテスト。挿入が失敗した場合、挿入が失敗したことをどのように知ることができますか? 挿入してからクエリを実行することでテストできますが、クエリが間違っていなかったことをどのように確認できますか?
3. 更新と削除のテスト -- 挿入のテストと同じ

これらを行うためのベストプラクティスは何ですか?

SQL のテストについて: これが可能であることは承知していますが、NHibernate のような O/R マッパーを使用すると、出力クエリに使用されるエイリアスにいくつかの名前付けのいぼが付けられます。私はそれをテストすることができました。

すべてを放棄して、単に NHibernate を信頼する必要がありますか? それが賢明かどうかはわかりません。

アプリケーションにテスト スイートを追加しようとしていますが、.NET 3.5 用の新しいテスト フレームワークに移行できません。

使用するのに適したテスト フレームワークについて提案がある人はいますか?

ここ数年、.NET コミュニティではテスト駆動開発が大流行しています。最近、ALT.NET コミュニティで BDD に関する不満を耳にしました。それは何ですか？TDDとの違いは何ですか？

SetUp 属性でマークされた SetUp メソッドを持つ MbUnit テスト フィクスチャをいくつか作成しました。これらのメソッドは、MbUnit GUI、コンソール ランナー、および ReSharper MbUnit プラグインを使用して、テストの前に正常に実行されます。しかし、TestDriven.NET でテストを実行すると、SetUp メソッドがまったく実行されません。

これが TestDriven.NET のバグなのか、それとも設定が間違っているのか、誰にもわかりませんか?

多くの人が、コードを書き始める前に、コードのテストを書くことについて話します。この方法は、一般にテスト駆動開発または略してTDDとして知られています。この方法でソフトウェアを作成することでどのようなメリットがありますか？この練習を始めるにはどうすればよいですか？

シールされたクラスをモックすることは、非常に面倒です。私は現在、これを処理するためにAdapter パターンを好みますが、単に維持することについては何かが奇妙に感じます。

では、封印されたクラスをモックする最良の方法は何ですか?

Java の回答は大歓迎です。実際、Java コミュニティはこれに長く取り組んでおり、多くのことを提供していると思います。

ただし、.NET に関する意見の一部を次に示します。

• C# 開発者にとってダックタイピングが重要な理由
• モック用のシール型およびその他の型のラッパーの作成
• WCF (および Moq) の単体テスト

失敗時にスローされる関数をテストする最良の方法は何ですか? または、障害の影響をかなり受けない機能をテストしますか?

例えば; I/O Completion Portポートを正しく初期化できない場合にコンストラクターをスローするクラスがあります。これは、イニシャライザ リストのWin32関数を使用します。CreateIoCompletionPortハンドルが正しく設定されていない場合 (null 以外の値)、コンストラクターは例外をスローします。この関数が失敗するのを見たことがありません。

これ（および私のコード内の同様の他の関数）が失敗した場合、コードは空白を含めて50行の長さであるため、私の質問は

a）それがスローされることをテストする価値は
ありますか b）テストする価値がある場合、どのように？
c) 単体テストが必要なため、単純なラッパー クラスを使用する必要がありますか?

CreateIoCompletionPortb) については、値をオーバーライドして渡すことを考えました。単体テストではそれをオーバーライドし、特定の値が渡されたときに 0 を返すようにします。ただし、これはコンストラクターで使用されるため、これは静的である必要があります。これは有効に見えますか？

私のほとんどの C++ プロジェクトでは、次のように ASSERTION ステートメントを多用しました。

しかし、TDD コミュニティは次のようなことを楽しんでいるようです。

私の経験では、最初のアプローチで非常に多くの微妙なバグを取り除くことができました。しかし、TDD アプローチは、レガシー コードを処理するための非常に賢明なアイデアです。

「Google」 - 彼らは「FIRST METHOD」を「救命胴衣を着て海岸を歩き、安全ガードなしで海を泳ぐ」と比較します。

どちらの方がよいですか？ソフトウェアを堅牢にするのはどれですか?

単体テストと ASP.NET Web アプリケーションは、私のグループではあいまいな点です。多くの場合、優れたテスト プラクティスは見過ごされ、Web アプリケーションはテストなしで数年間稼働することになります。

この問題点の原因は、通常、開発中に UI 自動化を作成する手間に関係しています。

あなたまたはあなたの組織は、TDD のベスト プラクティスを Web アプリケーション開発とどのように統合していますか?

私は TDD に精通しており、職場と自作の Web アプリケーションの両方で TDD を使用しています。ただし、Web アプリケーションで TDD を使用するたびに、Web サーバーに完全にアクセスできるという贅沢がありました。つまり、サーバーを更新して、サーバーから直接単体テストを実行できます。私の質問は、サード パーティの Web ホストを使用している場合、単体テストをどのように実行するのですか?

アプリが適切に設計されていて、ビルド プロセスが健全で自動化されている場合、実稼働サーバーで単体テストを実行する必要はないと主張することもできますが、個人的には、その後もすべてが「グリーン」であることを知って安心できるのが好きです。メジャーアップデート。

「展開する前にテストしてください」と「ステージング サーバーを持っていませんか?」と答えたすべての人にとって、私はあなたがどこから来ているのか理解しています。ステージング サーバーと CI プロセスをセットアップしています。私の単体テストは実行され、本番環境への更新の前にすべてが合格することを確認しています。

完璧な世界では、私はこれに関心がないことを理解しています. しかし、私はそれが起こるのを見たことがあります。ファイルが更新から除外された場合、または SQL スクリプトが実行されなかった場合、単体テストを実行するとその影響がすぐにわかりますが、それらがないとかなりの時間気付かないことがあります。

ここで私が求めているのは、私自身の強迫観念を満たすためだけに、アプリケーションをインストールできないサーバーまたはリモートにあるサーバー (たとえば、FTP アクセスしかできないサーバー) で単体テストを実行する方法があるかどうかです。ファイルを更新するために）？