問題タブ [tdd]

MessageQueue.GetPublicQueues を呼び出すクラスを表すために、RhinoMocks でモック オブジェクトを使用しています。メッセージ キューイングがワークグループ モードで動作しているときにスローされる例外 (MessageQueueException) をシミュレートして、例外を正しくキャッチしていることを確認したい

MessageQueueException には public コンストラクターはなく、例外用の標準の保護コンストラクターのみがあります。モック オブジェクト/Expect.Call ステートメントからこの例外をスローする適切な方法はありますか?

単体テストは私にとって素晴らしいことのように思えますが、それが重要な価値を持っていることを他の人に納得させることができない限り、実際にそれを学ぶことに時間を費やすべきかどうかはわかりません. 私は、他のプログラマー、そしてさらに重要なことに、管理部門のビーン カウンターに、テスト フレームワークの学習、テストの作成、テストの更新の維持などに費やされた余分な時間はすべて元が取れることを納得させなければなりません。

どのような証拠がありますか？単体テストを使用するチームと使用しないチームの 2 つの別々のチームで同じソフトウェアを実際に開発し、結果を比較した人はいますか? 疑わしい。「インターネットで調べて、みんなが話題にしているので、それは正しいことだ」と正当化することになっているのでしょうか?

単体テストが努力する価値があることを素人に納得させる確固たる証拠はどこにありますか?

私は MVCStoreFront アプリで Rob Connery の Web キャストを見ていました。

次のようなテストがあります。

私はすべて単体テストに賛成ですが、この形式のテスト ファースト開発が本当に有益かどうか疑問に思うことがあります。たとえば、実際のプロセスでは、コードの上に 3 ～ 4 層があります (ビジネス リクエスト、要件ドキュメント、アーキテクチャ ドキュメント) 、実際に定義されたビジネス ルール (割引価格は価格 - 割引) が誤って定義されている可能性があります。

その場合、単体テストは何の意味もありません。

さらに、単体テストは別の障害点です。

今、テストに欠陥があります。明らかに単純なテストでは大したことではありませんが、複雑なビジネス ルールをテストしているとしましょう。ここで何を得るのですか？

保守開発者がアプリケーションを保守している 2 年間、アプリケーションの寿命を早送りします。ビジネスがルールを変更し、テストが再び失敗し、一部の新人開発者がテストを誤って修正しました...ここで、別の障害点が発生しました。

私が見ているのは、より多くの可能性のある障害点だけであり、実際に有益なリターンはありません.割引価格が間違っていても、テストチームは問題を見つけます.ユニットテストはどのように作業を節約しましたか?

ここで何が欠けていますか？今のところ、TDD を有用なものとして受け入れるのに苦労しているので、TDD を愛するように教えてください。プログレッシブであり続けたいので、私もそうしたいのですが、それは私には意味がありません。

編集: テストが仕様の強制に役立つと何人かの人々が言及し続けています。多くの場合、仕様も間違っていたというのが私の経験ですが、仕様を書くべきではない人によって仕様が書かれている組織で働く運命にあるのかもしれません。

次のコードで依存関係を分離するのに苦労しています:

本来は外部サイトへのリクエストに頼らず単体テストを行いたい。

これについて最善の方法は何ですか？

私たちは他の開発者が使用するフレームワークを構築しており、今のところ多くの TDD プラクティスを使用しています。どこにでもインターフェースがあり、インターフェースを模擬するよく書かれた単体テストがあります。

ただし、入力クラスのプロパティ/メソッドの一部を内部にする必要があり、フレームワーク ユーザーには表示されないようにする必要があります (オブジェクト Id など)。問題は、インターフェイスがアクセシビリティを記述していないため、これらのフィールド/メソッドをインターフェイスに配置できないことです。

我々は出来た：

1. メソッドの最初の行で引き続きインターフェイスとアップキャストを使用しますが、それはインターフェイスの目的を無効にしているようです。
2. クラスを入力パラメーターとして使用する -すべてがインターフェイスでなければならないという TDD ルールを破る
3. パブリック インターフェイスと内部インターフェイスの間で何らかの変換を行う別のレイヤーを提供する

これに対処するための既存のパターン/アプローチはありますか? TDDの人々は何をすべきだと言っていますか?

テスト駆動開発の定義原則の 1 つは、最初に単体テストを作成し、次にそれらの単体テストに合格するコードを作成することであることは知っていますが、このようにする必要はありますか?

主に、私が取り組んできた過去のいくつかのプロジェクトは、設計されたものではなく、概念実証から進化したものであるため、それを書くまで何をテストしているのかわからないことがよくあります。

以前に単体テストを書こうとしたことがありますが、それは役に立つかもしれませんが、私には自然に思えません。

テスト駆動型開発担当者は、何かが機能するかどうかを確認するために何かをコーディングすることを含む、迅速で探索的な調査、つまりスパイクを指します。

彼らがその言葉を思いついた理由はありますか？

更新:ケント・ベックによるコインは、私には「オリジナル」のもののように見えますが、彼の言葉の使い方は、私の意見ではあまり意味がありません. 簡単なテストをコーディングすることは、「プロジェクトにスパイクを入れること」ですか?

興味深いことに、彼はこの用語を使用するのをやめたようです。なぜなら、この用語がさまざまな人々にさまざまな意味を呼び起こしたからです - 証拠については以下を参照してください!

私はいくつかのパブリックメソッドとプライベートメソッドを持つクラスライブラリを構築しています。プライベートメソッドをユニットテストできるようにしたいと思います（主に開発中ですが、将来のリファクタリングにも役立つ可能性があります）。

これを行う正しい方法は何ですか？

私は最近コードカバレッジツール（特にEmmaとEclEmma）を使い始めましたが、単体テストの完全性と、単体テストがコードのどの領域にないかを確認できるという見方が本当に気に入っています。まったくヒットしません。私は現在、単体テストをあまり行わない組織で働いています。私は、すべての人に単体テストとコードカバレッジ、およびTDDを実施し、できれば組織を変換するように促す予定です。

このテーマについて私が確信していない問題の1つは、コードカバレッジをどこまで実行する必要があるかということです。たとえば、次のようなクラスがある場合：

equals()正しく機能すること、期待どおりの結果が得られることなどを確認するために、いくつかの簡単な単体テストを作成しgetValue()ました。しかし、EclEmmaの視覚的な性質のおかげで、hashcode()メソッドは「テストされていない」場合は明るい赤で表示されます。

hashCode()この例では、実装がいかに簡単であるかを考えると、わざわざテストする価値がありますか？このメソッドの単体テストを追加して、コードカバレッジを％向上させ、EclEmmaがこれらの行に追加する明白な赤いハイライトを取り除くように感じます。

神経症でOCDに似ているかもしれませんが、EclEmmaのようなものを使用すると、テストされていないものを簡単に確認できます。プラグインはソースコードを赤で強調表示し、カバーされたコードは緑で強調表示します。できるだけ多くのクラスを100％グリーンにするようにプッシュします-それがあまりメリットをもたらさない場合でも。

TDD を使用して開発されたプロジェクトはリファクタリングが容易であると聞いたことがあります。これを実践すると、包括的な一連の単体テストが得られるためです。変更によってコードが破損した場合は (うまくいけば) 失敗します。ただし、これについて私が見たすべての例は、リファクタリングの実装を扱っています。たとえば、アルゴリズムをより効率的なものに変更します。

アーキテクチャのリファクタリングは、設計がまだ練られている初期段階でより一般的であることがわかりました。インターフェイスが変更され、新しいクラスが追加および削除され、関数の動作がわずかに変更される可能性もあります (これを行うには必要だと思っていましたが、実際にはそれを行う必要があります)、など...しかし、各テストケースが密結合されている場合これらの不安定なクラスに対して、設計を変更するたびにテスト ケースを常に書き直さなければならないのではないでしょうか?

TDD では、どのような状況でテスト ケースを変更および削除しても問題ありませんか? テスト ケースを変更しても問題が発生しないことをどのように確認できますか? さらに、常に変化するコードと包括的なテスト スイートを同期させるのは大変なことのようです。ソフトウェアが構築され、安定し、機能するようになると、単体テスト スイートがメンテナンス中に非常に役立つことは理解していますが、TDD は早い段階でも役立つはずですが、それはゲームの後半です。

最後に、TDD やリファクタリングに関する優れた本は、この種の問題に対処するものでしょうか? もしそうなら、あなたはどちらをお勧めしますか？