タグ付けされた質問 「tdd」

私のプログラムの統合テストがすでにあり、それらすべてが合格した場合、それはうまくいくと感じています。次に、単体テストを作成/追加する理由は何ですか？とにかく統合テストを書く必要があるので、統合テストでカバーされていない部品の単体テストのみを書きたいと思います。 統合テストよりも単体テストの利点を知っているのは 小さく、したがって高速に実行できます（ただし、テストに新しいユニットを追加すると、統合テストで既にテストされているため、テストスーツ全体が大きくなり、実行時間が長くなります） 1つのことしかテストしないため、バグを見つけやすくなります（ただし、統合テストが失敗した場合は、個々のパーツを検証するために単体テストの書き込みを開始できます） 統合テストで検出されない可能性のあるバグを見つけます。たとえば、マスキング/オフセットのバグ。（ただし、統合がすべてのパスをテストする場合、プログラムは隠れたバグが存在する場合でも動作します。したがって、将来の統合テストを中断したり、パフォーマンスの問題を引き起こさない限り、これらのバグを見つける/修正することは優先度が高くありません） そして、私たちは常により少ないコードを書きたいのですが、単体テストを書くにはもっと多くのコードが必要です（主にモックオブジェクトをセットアップします）。単体テストと統合テストのいくつかの違いは、単体テストではモックオブジェクトを使用し、統合テストでは実際のオブジェクトを使用することです。重複が多く、コードの動作を変更するためのオーバーヘッドが追加されるため、テストでもコードの複製は好きではありません（リファクタリングツールは常にすべての作業を行うことはできません）。

47 testing  unit-testing  tdd  integration-tests 

この質問は、単体テストフレームワークに関するものではありません。 この質問は、単体テストの作成に関するものではありません。 この質問は約あるところ書かれたUTのコードを配置する方法と、/とき/コンパイルし、それを実行する場所。 レガシーコードを効果的に使用するにあたって、Michael Feathersは次のように主張しています。 優れた単体テスト...高速で実行 そしてそれ 実行に1/10秒かかる単体テストは、低速の単体テストです。 これらの定義は理にかなっていると思います。私はまた、ユニットテストのセットと、より長い時間がかかるコードテストのセットを別々に保持する必要があることを示唆していると思いますが、それが（非常に）高速に実行される場合、ユニットテストと呼ばれるものだけに支払う代償だと思います。 明らかに問題 ++ Cでは、「実行」へのあなたのユニットテスト（複数可）、あなたがする必要があります。 コードを編集します（使用している「サイクル」に応じて、本番またはユニットテスト） コンパイル リンク 単体テスト実行可能ファイルの開始（s） 編集（奇妙な近い投票の後）：詳細に入る前に、ここでポイントを要約してみます： （テスト）コードの編集とテストコードの実行の両方が効率的になるように、C ++ユニットテストコードを効果的に編成するにはどうすればよいですか？ 最初の問題は、その後、決定することですどこようにユニットテストコードを配置します： 関連する製品コードと組み合わせて編集および表示するのは「自然」です。 現在変更しているユニットのコンパイルサイクルを開始するのは簡単です。 次に、関連する2番目の問題は、フィードバックが瞬時に行われるようにコンパイルするものです。 極端なオプション： 各Unit-Test-Test-Unitは個別のcppファイルに存在し、このcppファイルは（テストするソースコードのユニットファイルと共に）個別にコンパイルおよびリンクされ、単一の実行可能ファイルにリンクされます。 （+）これにより、単一のテストユニットの起動（コンパイル+リンク！）時間を最小限に抑えることができます。 （+）テストは1つのユニットのみをテストするため、超高速で実行されます。 （-）スイート全体を実行するには、膨大な数のプロセスを開始する必要があります。管理することが問題になる場合があります。 （-）プロセス開始のオーバーヘッドが見えるようになる 反対側は、テストごとに1つのcppファイルを持っていますが、すべてのテストcppファイルは（テストするコードとともに）1つの実行可能ファイルにリンクされています（モジュールごと/プロジェクトごと/選択を選択してください）。 （+）変更されたコードのみがコンパイルされるため、コンパイル時間は問題ありません。 （+）実行するexeは1つしかないため、スイート全体の実行は簡単です。 （-）任意のオブジェクトを再コンパイルすると再リンクがトリガーされるため、スイートはリンクするのに時間がかかります。 （-）（？）スーツの実行には時間がかかりますが、すべてのユニットテストが高速であれば、時間は問題ないはずです。 それでは、実際のC ++ 単体テストはどのように処理されますか？夜間/毎時だけ実行する場合、2番目の部分は実際には重要ではありませんが、最初の部分、つまりUTコードを本番コードに「結合」する方法です。フォーカスは常に重要だと思います。（そして、開発者がUTコードに焦点を合わせている場合、彼らはそれを実行したいと思うので、パート2に戻ります。） 現実世界の物語と経験に感謝します！ ノート： この質問は、意図しないプラットフォームとメイク/プロジェクトシステムを意図的に残します。 質問タグ付きUT＆C ++は開始するのに最適な場所ですが、残念ながらあまりにも多くの質問、特に回答が詳細や特定のフレームワークに集中しすぎています。 少し前に、ブーストユニットテストの構造に関する同様の質問に答えました。この構造は、「実際の」高速な単体テストには欠けていることがわかりました。そして、私は他の質問が狭すぎると思うので、この新しい質問です。

47 c++  unit-testing  tdd  projects-and-solutions 

最近は大流行です。「みんな」がそれをお勧めします。それ自体が疑わしいものです。 テストファースト（テスト駆動）開発を行うときに発見したいくつかの欠点は何ですか？私は知識のある開業医からの個人的な経験を探しています。私はインターネット上の他の場所にある百人の夢想家の仮説を読むことができます。 TDDが嫌いだからではなく、ソフトウェア開発プロセスを改善することが私の仕事であり、人々が遭遇する問題について学ぶことができれば、プロセスを改善できる可能性が高くなるからです。

47 development-process  tdd 

どのようにしてユニットマネージャーにあなたをマネージャーに納得させましたか？ 「使用」とは、ソース管理への開発、チェックイン、および長期にわたる単体テストの維持などを許可することを意味します。 一般的な管理の反対意見は次のとおりです。 顧客は単体テストの費用を支払わなかった このプロジェクトでは、単体テストの時間が許可されていません 技術的負債？どのような技術的負債ですか？ 他の異議を知っていますか？あなたの答えは何でしたか？ 前もって感謝します！

46 project-management  management  unit-testing  tdd 

TDD（テスト駆動開発）を行わない場合、自分自身（またはチーム）を「アジャイル」と正しく呼ぶことは可能ですか？

45 agile  tdd 

これまでのところ、テスト駆動開発を理解しているので、失敗した（赤の）単体テストがある場合にのみ生産的なコードを書くことができます。これに基づいて、テスト駆動アプローチを他の形式のテストにも適用できるかどうか疑問があります。

41 testing  tdd 

赤、緑、リファクタリングのサイクルを実行するときは、常にテストに合格するための最小限のコードを記述する必要があります。これは私がTDDについて教えられてきた方法であり、ほとんどすべての本がプロセスを説明する方法です。 しかし、ロギングはどうですか？ 正直なところ、実際に複雑なことが起こっていない限り、アプリケーションでのログ記録はほとんど使用していませんが、適切なログ記録の重要性に関する多くの投稿を見てきました。 そのため、例外をログに記録する以外に、適切にテストされたアプリケーション（ユニット/統合/受け入れテスト）にログを記録することの本当の重要性を正当化できませんでした。 だから私の質問は： TDDを実行している場合、ログを記録する必要がありますか？テストに失敗しても、アプリケーションのどこが悪いのかわかりませんか？ 各クラスの各メソッドにロギングプロセスのテストを追加する必要がありますか？ たとえば、実稼働環境でいくつかのログレベルが無効になっている場合、テストと環境の間に依存関係が生じませんか？ 人々はログがデバッグを容易にする方法について話しますが、TDDの主な利点の1つは、テストの失敗によって何が間違っているかを常に知っていることです。 私がそこに欠けているものはありますか？

40 design  object-oriented  unit-testing  tdd  logging 

私たちのプロジェクトでは、ほぼ1,000のテストがあり、非常に時間がかかるため、チェックインを実行する前にテストの実行に煩わされることがなくなりました。せいぜい、変更したコードに関連するテストを実行するだけで、最悪の場合はテストせずにチェックインするだけです。 この問題は、ソリューションが120のプロジェクト（通常、はるかに小さいプロジェクトを行い、TDDを適切に行うのは2回目です）に成長し、ビルド+テスト時間が約2〜3分になったためであると思います小さいマシンで。 テストの実行時間を短縮するにはどうすればよいですか？テクニックはありますか？もっと偽物？偽造が少ない？すべてのテストを実行するときに、より大きな統合テストが自動的に実行されるべきではないでしょうか？ 編集：いくつかの回答への応答として、私たちはすでにCIとビルドサーバーを使用しています。これがテストの失敗を知る方法です。問題（実際には症状）は、失敗したビルドに関するメッセージを継続的に取得することです。部分テストの実行は、ほとんどの人が行うことですが、すべてではありません。そしてテストに関しては、実際にはかなりうまく作られており、すべてに偽物を使用しており、IOはまったくありません。

40 c#  unit-testing  tdd  nunit 

統合テストに関するJB Rainsbergerのブログ投稿を読んでいますが、どのように統合テストが私たちの設計により厳しいのでしょうか？ より統合されたテストを作成します。これはより大きく、マイクロテストのように設計を厳しく批判しません。

38 tdd  integration-tests 

コードに既知の欠陥が含まれていますが、修正する必要がありますが、まだ修正されておらず、現在のリリースでは修正されず、近い将来修正されない可能性がある場合、テストスイート？単体テストを追加すると、（明らかに）失敗します。失敗したテストに慣れるのは悪い考えのようです。一方、既知の欠陥であり、既知の失敗事例がある場合、ある時点で修正されるべきであり、テストはすでに利用可能であるため、テストスイートに入れないようにするのは奇妙に思えます。

37 unit-testing  tdd 

しばらくの間、コードの単体テストを書くことを学んでいます。 最初は、真のTDDを開始しました。最初に失敗したテストを記述するまで、コードを記述しませんでした。 しかし、最近、多くのコードが関係する解決しにくい問題がありました。テストとコードの記述に数週間を費やした後、私は全体のアプローチが機能しないという不幸な結論に至り、2週間の作業を捨ててやり直す必要がありました。 これは、コードを作成したばかりの場合には十分な判断ではありませんが、数百のユニットテストを作成した場合、すべてを捨てるのはさらに感情的に困難になります。 概念実証のためにコードをまとめて、その後自分のアプローチに満足したらテストを書くことができたのに、これらのテストを書くのに3日間または4日間の努力を無駄にしたと考えるのは仕方ありません。 TDDを実践する人々は、このような状況を適切に処理しますか？いくつかのケースでルールを曲げる場合はありますか、それともコードが役に立たないことが判明した場合でも、常に最初にテストを慎重に書くのですか？

37 tdd  refactoring 

今日、私たちはTDDをトレーニングしていて、次の誤解のポイントを見つけました。 タスクは、入力 "1,2"が3である数値の合計を返すためのものです。（C＃で）私が書いたのは： numbers = input.Split(','); return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct しかし、他の人はそれを別の方法で行うことを好みました。まず、入力 "1,2"について、次のコードを追加しました。 if (input == "1,2") return 3; 次に、入力 "4,5"のテストをもう1つ導入し、実装を変更しました。 if (input == "1,2") return 3; else if (input == "4,5") return 9; そしてその後、彼らは「さて、今はパターンが見える」と言って、私が最初にやったことを実装しました。 2番目のアプローチはTDDの定義により適していると思いますが、...厳密にすべきでしょうか？私にとっては、些細な赤ちゃんのステップをスキップして、何もスキップしないことを十分に確信している場合は、それらを「ツインステップ」に結合してもかまいません。私が間違っている？ 更新。私はそれが最初のテストではないことを明確にしないことで間違いを犯しました。すでにいくつかのテストが行​​われているため、「return 3」は実際に要件を満たすための最も単純なコードではありませんでした。

37 testing  tdd 

大規模な現実の複雑なプロジェクトでTDDを使用する良い例は何でしょうか？これまでに見た例はすべて、本や論文を目的としたおもちゃのプロジェクトです... TDDを多用するオープンソースプロジェクトに名前を付けることはできますか？C ++が望ましいですが、JavaとC＃または他の類似言語を読むことができます。

37 java  c#  open-source  c++  tdd 

私は歴史的にユニットテストを行っていない新しいチームで働いています。私の目標は、チームが最終的に TDD（テスト駆動開発）を自然なプロセスとして採用することです。しかし、TDDはユニットテスト以外のチームにとっては非常に急進的であるため、コーディング後にユニットテストを書くことから始めようと思いました。 誰も同じような状況にありましたか？チームがユニットテストを行っていないときにTDDに慣れるのに効果的な方法は何ですか？いくつかの手順でこれを行うのは理にかなっていますか？それとも、すぐに飛び込み、成長するすべての痛みに一度に直面する必要がありますか？ 編集 明確にするために、チームには（私以外に）単体テストの暴露/経験を持つ人はいません。また、Visual Studioに組み込まれている単体テスト機能の使用を計画しています。

37 unit-testing  tdd 

このことを考慮： public function polynominal($a, $b, $c, $d) { return $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d; } 上記の機能に対してさまざまなテストを作成し、自分や他の人に「機能する」ことを証明するとします。 その後、これらのテストを削除して、いつまでも幸せに生きてみませんか？私のポイントは、いくつかの機能が機能することが証明された後、継続的にテストする必要がないことです。私は、これらの機能をまだテストする必要があると述べているカウンターポイントを探しています：...または、はい、これらはテストする必要はありません...

36 php  unit-testing  testing  tdd