問題タブ [tdd]

そのようなコードを考えると：

ベクトルに 3 つの値を入力すると、関数が適切な順序と数で呼び出されることをテストしたいと思います。たとえば、私のテストは次のようになります。

これをどのようにテストすることをお勧めしますか? CppUnit または GoogleTest フレームワークでこれを行う手段はありますか? たぶん、他のユニットテストフレームワークでそのようなテストを実行できるでしょうか?

これらの関数からデバッグ関数を呼び出さないとおそらくこれは不可能であることは理解していますが、少なくとも一部のテスト フレームワークでは自動的に実行できます。トレース ログをスキャンしてその正確性を確認するのは好きではありません。

UPD: I'm trying to check not only the state of an objects, but also the execution order to avoid performance issues on the earliest possible stage (and in general I want to know that my code is executed exactly as I expected).

最近、Python で GUI アプリケーションを開発しながら TDD を試しています。コードの機能を検証するテストがあることは非常に心強いことですが、TDD の推奨されるプラクティスのいくつかに従うのは難しいことです。つまり、最初にテストを書くのは大変でした。また、テストを読みやすくするのが難しいと感じています (モッキング ライブラリを多用しているため)。

私はmockerというモッキングライブラリを選びました。私がテストしているコードの多くは、(a) システム状態に依存するアプリケーション内の他のメソッド、または (b) イベント ループなしでは存在できない ObjC/Cocoa オブジェクトなどを呼び出すため、これをよく使用します。

とにかく、次のようなテストがたくさんあります。

これは実際には 3 つのテストであることに注意してください。すべて同じパラメータ化されたテスト関数を使用します。テスト中のコードは次のとおりです。

モッカーを使用して気づいたことの 1 つは、最初にアプリケーション コードを書き、次に戻ってテストを書く方が簡単だということです。呼び出しは、アプリケーション コードよりもはるかに冗長です (したがって、記述するのが難しくなります)。アプリ コードを記述し、それからテスト コードをモデル化する方が簡単です。

このテスト方法 (および少しの規律) により、100% のテスト カバレッジでコードを簡単に記述できることがわかりました。

これらのテストが良いテストであるかどうか疑問に思っていますか? 良いテストを書く秘訣を最終的に発見したとき、この方法を後悔するでしょうか?

テストが無駄になるほど、TDD のコア原則に違反していませんか?

私はTDDについて複雑な気持ちを持っています。私はテストを信じていますが、テストが私の開発努力を促進するという考えには問題があります。

現在の要件を満たすインターフェイス用に記述されたいくつかのテストを満たすようにコーディングする場合、保守可能なコードの構築、クリーンな設計、および健全なアーキテクチャから焦点を移す可能性があります。

テストではなく、駆動に問題があります。何かご意見は？

私はDIと単体テストを始めたばかりで、経験豊富な開発者にとっては簡単なことだと確信している障害にぶつかりました:

データを受信して​​データベースに保存する MessageManager というクラスがあります。同じアセンブリ (Visual Studio のプロジェクト) 内で、データベースへのアクセスに必要なすべてのメソッドを備えたリポジトリ インターフェイスを作成しました。このインターフェイスの具体的な実装は、DataAccess という別のアセンブリにあります。

そのため、DataAccess は、リポジトリ インターフェイスについて知るために MessageManager へのプロジェクト参照を必要とします。また、MessageManager のクライアントがリポジトリ インターフェイスの具体的な実装を挿入できるように、MessageManager には DataAccess へのプロジェクト参照が必要です。これはもちろん許可されていません

インターフェイスをデータ アクセス アセンブリに移動することもできますが、リポジトリ インターフェイスは、それを使用するクライアントと同じアセンブリに存在することを意図していると思います

それで、私は何を間違ったのですか？

JavaでJMockを使用してオブジェクト構築をモックする方法はありますか?

たとえば、そのようなメソッドがある場合:

...テストメソッドでオブジェクト構築の期待をモックアウトする方法はありますか?

型をチェックするための余分なコードを用意するのではなく、特定のコンストラクターが呼び出されていることを期待できるようにしたいと考えています (私の例のように常に複雑で単純であるとは限らないため)。

したがって、代わりに：

特定のコンストラクターが呼び出されることを期待できます。少しきれいにして、実際にテストされているものをより読みやすい方法で表現するためです。

単純な例で申し訳ありませんが、私が取り組んでいる実際の問題はもう少し複雑ですが、期待することで単純化できます。

もう少し背景について：

ラッパー オブジェクトを作成する単純なファクトリ メソッドがあります。ラップされるオブジェクトは、テスト クラス (既存のコード) で取得するのが難しいパラメーターを必要とする場合があるため、それらを構築することは困難です。

おそらく、私が実際に探しているものに近いのは、スタブするすべてのメソッドを指定せずに、(CGLib を使用して) クラス全体を一気にモックする方法はありますか?

したがって、モックはコンストラクターにラップされているため、明らかにメソッドを呼び出すことができます.JMockは各メソッドを動的にモックアウトできますか?

それはかなり複雑になるので、私の推測ではノーです。しかし、私が間違ったツリーを吠えていることを知っていることも価値があります:-)

JavaScript で UI を開発する際に、TDD の原則に正しく従う最善の方法を見つけようとして、私は多くの苦労をしました。これについて最善の方法は何ですか？

ビジュアルを機能から分離するのが最善ですか? 最初にビジュアル要素を開発してから、テストを作成してから機能のコードを作成しますか?

私の友人は、職場で TDD とピンポン ペアリングを行う方法を説明していました。つまり、テスト作成者がキーボードを実装者に渡すと、実装者はテストに合格するために最も単純な (そして時には間違ったことを) しようとします。

たとえば、GetName() メソッドをテストしていて、テストが「Sally」をチェックする場合、GetName メソッドの実装は次のようになります。

もちろん、これは（単純に）テストに合格します。

彼は、これにより、コンポーネントの実際の動作や期待される状態をテストするのではなく、特定の定型値をチェックする単純なテストをなくすことができると説明しています。また、より多くのテストを作成し、最終的には設計を改善してバグを減らすのにも役立ちます。

いい感じですが、彼との短いセッションでは、1回のテストを通過するのに他の場合よりもはるかに時間がかかったように見え、多くの余分な価値が得られたとは感じませんでした.

あなたはこのアプローチを使用していますか?

単体テストのガイドラインと推奨事項がどこにあるか知っている人はいますか? 次の種類のトピックに対応するものを用意したいと思います (たとえば)。

• テストはアプリケーション ロジックと同じプロジェクトにある必要がありますか?
• ロジック クラスをミラーリングするテスト クラスを用意する必要がありますか?それとも必要な数だけテスト クラスを用意する必要がありますか?
• テスト クラス、メソッド、およびプロジェクトにどのように名前を付ける必要がありますか (それらが別のプロジェクトにある場合)
• プライベート、保護、および内部メソッドをテストする必要がありますか、それともパブリックにアクセスできるものだけをテストする必要がありますか?
• 単体テストと統合テストは分離する必要がありますか?
• 100% のテスト カバレッジが得られない正当な理由はありますか?

私は何を求めていないのですか？

オンライン リソースが最適です。

大規模なMFCUIアプリケーションをどのように単体テストしますか？

長年開発されてきた大規模なMFCアプリケーションがいくつかあります。いくつかの標準的な自動QAツールを使用して、基本的なスクリプトを実行し、ファンダメンタルズをチェックしたり、ファイルを開いたりします。これらは、デイリービルド後にQAグループによって実行されます。

ただし、個々の開発者がコードをデイリービルドに送信する前に、ダイアログ、メニュー、およびアプリケーションの他の視覚要素に対してテストをビルドして実行できるような手順を紹介したいと思います。

デバッグビルドでのみ表示されるダイアログの非表示のテストボタンなどの手法について聞いたことがありますが、このための標準的なツールキットはありますか。

環境は、C ++ / C / FORTRAN、MSVC 2005、Intel FORTRAN 9.1、Windows XP / Vista x86＆x64です。

• TDD の価値に気付くのが遅すぎたとしましょう。プロジェクトはすでに成熟しており、多くの顧客が使用を開始しています。
• 使用される自動テストは、ほとんどが機能/システム テストであり、自動化された GUI テストがかなりあるとします。
• 新しい機能のリクエストと新しいバグ レポート (!) があるとします。そのため、かなりの開発がまだ続いています。
• 単体テストがない、またはほとんどないビジネスオブジェクトがすでにたくさんあることに注意してください。
• それらの間のコラボレーション/関係が多すぎます。これも、より高いレベルの機能/システム テストによってのみテストされます。統合テスト自体はありません。
• 多数のテーブル、ビューなどを備えた大規模なデータベースが配置されています。単一のビジネス オブジェクトをインスタンス化するだけでも、すでにかなりの量のデータベース ラウンド トリップが行われています。

この段階でTDDをどのように導入できますか?

嘲笑するのが道のようです。しかし、ここで行う必要がある嘲笑の量は多すぎるように思えます。既存のもの (BO、データベースなど) で動作するモッキング システムのために、精巧なインフラストラクチャを開発する必要があるように思えます。

つまり、TDD はゼロから始める場合にのみ適切な方法論であるということですか? すでに成熟した製品に TDD を導入するための実現可能な戦略について知りたいです。