問題タブ [tdd]

プロジェクトのどの部分で、単体テストを書くことがほとんど、または本当に不可能ですか? データアクセス？ftp?

この質問に答えがあるとすれば、100% のカバレッジは神話ですよね?

Visual Studio 2005 (Professional) を使用した C++ の一般的な TDD と単体テストの使用経験について聞くことに興味があります。

最初にいくつかの背景。かなり大規模なプロジェクトがあり、その多くは単体テストに CppUnit を使用して Linux で開発されています。プロジェクトはいくつかのライブラリに分割されており、それぞれに独自のテスト セットがあります。ライブラリをコンパイルし、テストスイートをコンパイルしてからテストを実行する簡単なスクリプトがあります。したがって、コードを変更した後、コマンド ラインから "test" を実行すると、テストが実行されます。

現在、ほとんどの開発者は、この製品の開発に Windows 上の Visual Studio 2005 を使用しています。もちろん、nmake を使用してコマンド ラインからテストを実行することもできますが、追加の手順が必要になるため、より統合されたソリューションが必要です。

したがって、私の質問には 2 つの部分があります。

まず、大規模なコード ベースでテスト用のコードをレイアウトする最良の方法は何ですか? ライブラリごとに 1 つずつ、ソリューションに複数のテスト プロジェクトを作成するのは普通ですか?

次に、CppUnit テストを Visual Studio に統合するためのツールはありますか? 依存関係が正しく設定されている場合、テスト プロジェクトを正しく実行するとテストが実行されるはずですが、現在、結果はコマンド ウィンドウに表示されます。

最近、BDD について聞いたことがありますが、TDD と非常によく似ていることがわかりました。

この 2 つのうち、どちらを使用しますか (もしあれば)。

それぞれの長所と短所はどれですか？

私のチームがテスト可能なコードを作成できるようにするために、C# コード ベースをよりテストしやすくするためのベスト プラクティスの簡単なリストを作成しました。(ポイントのいくつかは、C# のモッキング フレームワークである Rhino Mocks の制限に言及していますが、ルールはより一般的にも適用される可能性があります。) 従うベスト プラクティスはありますか?

コードのテスト容易性を最大化するには、次の規則に従います。

1. 最初にテストを書き、次にコードを書きます。理由: これにより、テスト可能なコードを記述し、コードのすべての行に対してテストが記述されるようになります。

2. 依存性注入を使用してクラスを設計します。理由: 見えないものをモックしたりテストしたりすることはできません。

3. Model-View-Controller または Model-View-Presenter を使用して、UI コードをその動作から分離します。理由: テストできない部分 (UI) を最小限に抑えながら、ビジネス ロジックをテストできるようにするため。

4. 静的メソッドまたはクラスを作成しないでください。 理由: 静的メソッドは分離が困難または不可能であり、Rhino Mocks はそれらをモックできません。

5. クラスではなく、インターフェイスからプログラムします。理由: インターフェイスを使用すると、オブジェクト間の関係が明確になります。インターフェイスは、オブジェクトがその環境から必要とするサービスを定義する必要があります。また、インターフェイスは、Rhino モックやその他のモック フレームワークを使用して簡単にモックできます。

6. 外部依存関係を分離します。理由: 未解決の外部依存関係はテストできません。

7. モックするメソッドを仮想としてマークします。理由: Rhino Mocks は非仮想メソッドをモックできません。

インメモリ データベースと開発データベースを比較してテストするのはいつですか?

また、関連する副次的な質問として、開発データベースを使用する場合、個別開発データベース、統合開発データベース、またはその両方を使用しますか?

また、++、単体テストの場合、リポジトリ/DAL などのモックアウトよりもインメモリ データベースを使用するのはいつですか?

そのプロファイルの所有者だけがアクセスできるプロファイルページがあるとします。このプロフィールページは次の場所にあります。

ユーザー/プロファイル/{userID}

ここで、他のユーザーによるこのページへのアクセスを防ぐために、UserControllerクラスのProfile関数を構造化して、現在のセッションのIDを確認できると思います。

HttpContext.Current.User.Identity.Name

IDがURLのIDと一致する場合は、次に進みます。それ以外の場合は、ある種のエラーページにリダイレクトします。

私の質問は、このようなものをどのようにユニットテストするのですか？コントローラーでHttpContextの代わりに何らかの依存性注入を使用してチェックを行う必要があると思いますが、それを行うための最良の方法がわかりません。どんなアドバイスも役に立ちます。

UI (またはサービス ファサード) から DB までのすべてのレイヤーの変更を必要とするユーザー ストーリーを実装していると仮定します。

どの方向に移動しますか？

• UIからビジネスレイヤー、リポジトリ、DBまで?
• DBからリポジトリ、ビジネスレイヤー、UIまで?
• 場合によります。（何の上に ？）

TDDを実行するとき、「このクラス/機能には十分なテストです」と伝えるにはどうすればよいですか?

つまり、すべてのエッジ ケースのテストを完了したと言えるのはいつですか?

私は以前、ZenTest と autotest を使用して Ruby プロジェクトに取り組んできました。以前は、この構成でテスト駆動開発に使用していました。私は現在Javaで取り組んでいるプロジェクトを持っています.Javaの世界に同じ効果を達成するために似たようなものがあるかどうか疑問に思っていました.

問題の記述からコードへの移行をどのように学んだかについて、この質問を拡張する 2 人が TDD について言及しました。

スターターが TDD に取り掛かる (そして将来の悪い習慣を避ける) ことは良いことでしょうか? それとも、プログラミング言語が何であるかを理解する段階には複雑すぎるでしょうか?