タグ付けされた質問 「unit-testing」

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

40 c#  unit-testing  tdd  nunit 

これは今しばらく私を悩ませてきたものです。APIクライアントの単体テストを実際に行う価値はありますか？ petshop REST APIへの呼び出しを抽象化するための小さなクラスを作成しているとしましょう。petshopは非常に単純なAPIであり、基本的なメソッドセットがあります。 listProducts() getProductDetails(ProductID) addProduct(...) removeProduct(ProductID) これをテストするには、モックサービスを作成するか、応答をモックする必要があります。しかし、それは行き過ぎのようです。タイプミス/構文エラーによってメソッドの動作が停止しないことを確認したいのですが、リモートメソッドを呼び出す関数を作成し、それらのリモートメソッドから偽の応答を作成しているため、努力の無駄であり、実際に失敗することのない何かをテストしています。さらに悪いことに、リモートメソッドが変更された場合、本番環境の使用が失敗している間にユニットテストに合格します。 何かが足りないのか、スティックの端が間違っているのか、木の代わりに木が見えないのはかなり確かです。誰かが私を正しい軌道に乗せることができますか？

38 unit-testing  api 

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

37 unit-testing  tdd 

コンストラクターで「新しい」を使用すること（単純な値オブジェクト以外のオブジェクト）を使用すると、単体テストが不可能になるため（これらのコラボレーターも作成する必要があり、モックできないため）悪い習慣であると読みました。ユニットテストの経験があまりないため、最初に学習するいくつかのルールを収集しようとしています。また、これは使用されている言語に関係なく、一般的に有効なルールですか？

37 unit-testing  constructors 

現在のプロジェクトのユニットテストをいくつか書き始めました。私は実際にそれを経験していません。最初に完全に「取得」したいので、現在IoCフレームワークもモックライブラリも使用していません。 ユニットテストでオブジェクトのコンストラクターにnull引数を提供することに何か問題があるのではないかと思っていました。サンプルコードを提供します。 public class CarRadio {...} public class Motor { public void SetSpeed(float speed){...} } public class Car { public Car(CarRadio carRadio, Motor motor){...} } public class SpeedLimit { public bool IsViolatedBy(Car car){...} } さらに別のCar Code Example（TM）は、質問にとって重要な部分のみに縮小されました。次のようなテストを作成しました。 public class SpeedLimitTest { public void TestSpeedLimit() { Motor motor = new Motor(); …

37 unit-testing 

ソースコードの単体テストの利点を宣伝するブログ、記事、ウェブサイトの無限のリストを見つけることができます。Java、C ++、C＃、およびその他の型付き言語用のコンパイラをプログラムした開発者は、ユニットテストを使用して作業を検証したことがほぼ保証されています。 それでは、なぜその人気にもかかわらず、これらの言語の構文にテストがないのでしょうか？ マイクロソフトはC＃にLINQを導入しましたが、なぜテストも追加できないのですか？ 私は、これらの言語の変更がどうなるかを予測するつもりはありませんが、そもそもなぜそれらが変更されないのかを明確にするつもりです。 例として：ステートメントのfor構文なしでループを書くことができることを知っていますfor。whileまたはif/ gotoステートメントを使用できます。誰かがfor声明がより効率的であると判断し、それを言語に導入しました。 テストがプログラミング言語の同じ進化に従っていないのはなぜですか？

37 programming-languages  unit-testing  syntax 

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

37 unit-testing  tdd 

ここで私の仕事でコードカバレッジのプッシュを開始し、考えさせられました。 コードカバレッジの収益が減少する時点に達するのはいつですか？良好なカバレッジと十分でないことの間のスイートスポットは何ですか？作成しているプロジェクトのタイプ（WPF、WCF、Mobile、ASP.NETなど）によって異なりますか（これらは私たちが書いているC＃クラスです）。

37 code-quality  unit-testing 

データベースに接続するテストクラスの方法に関する質問への回答があります。たとえば、「テストクラスがサービスを接続する必要があります...」や「ユニットテスト-データベース結合アプリ」などです。 したがって、要するに、データベースに接続する必要があるクラスAがあると仮定しましょう。Aに実際に接続させる代わりに、Aに接続に使用できるインターフェースを提供します。テストのために、このインターフェイスをいくつかのもので実装します-もちろん接続しません。クラスBがAをインスタンス化する場合、「実際の」データベース接続をAに渡す必要があります。ただし、Bはデータベース接続を開きます。つまり、Bをテストするには、接続をBに挿入します。ただし、BはクラスCなどでインスタンス化されます。 したがって、どの時点で「ここでデータベースからデータをフェッチし、このコードの単体テストを作成しません」と言う必要がありますか？ 言い換えると、あるクラスのコードのどこかで呼び出す必要がある、sqlDB.connect()またはそれに似たものです。このクラスをテストするにはどうすればよいですか？ また、GUIまたはファイルシステムを処理する必要があるコードでも同じですか？ ユニットテストをしたいです。他の種類のテストは私の質問とは関係ありません。私はそれで1つのクラスのみをテストすることを知っています（キリアンに同意します）。現在、一部のクラスはDBに接続する必要があります。このクラスをテストして「これを行うには」と尋ねると、多くの人が「依存性注入を使用してください！」と言います。しかし、それは問題を別のクラスにシフトするだけですよね？だから、本当に、本当に接続を確立するクラスをテストするにはどうすればいいですか？ おまけの質問：ここでの答えは、「模擬オブジェクトを使用してください！」どういう意味ですか？テスト対象のクラスが依存するクラスをモックします。ここでテスト対象クラスをモックし、実際にモックをテストします（テンプレートメソッドを使用するという考え方に近づきます。以下を参照）。

37 database  unit-testing 

ランダムな長さのランダムなパスワードを生成することを意図したクラスがありますが、定義された最小長と最大長の間に制限されています。 私は単体テストを作成していますが、このクラスで興味深い小さな障害に遭遇しました。単体テストの背後にある全体的な考え方は、繰り返し可能にする必要があるということです。テストを100回実行すると、同じ結果が100回得られるはずです。あなたが期待する初期状態にあるかもしれないし、そうでないかもしれないいくつかのリソースに依存しているなら、あなたのテストが本当に常に再現可能であることを保証するために問題のリソースをモックするつもりです。 しかし、SUTが不確定な出力を生成することになっている場合はどうでしょうか？ 最小長と最大長を同じ値に修正すると、生成されたパスワードが予想された長さであることを簡単に確認できます。しかし、許容範囲（たとえば15-20文字）の範囲を指定すると、テストを100回実行して100パスを取得できるという問題がありますが、101回目の実行で9文字の文字列が返される可能性があります。 コアが非常に単純なパスワードクラスの場合、大きな問題を証明すべきではありません。しかし、一般的なケースについて考えさせられました。設計によって不確定な出力を生成しているSUTを処理するときに取るのに最適な方法として通常受け入れられている戦略は何ですか？

37 unit-testing  random 

このことを考慮： 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 

YahtzeeゲームのTDDスタイルを書いているとしましょう。5つのサイコロのセットがフルハウスかどうかを判断するコードの一部をテストします。私の知る限り、TDDを行うときは、次の原則に従います。 最初にテストを書く 可能な限り簡単なことを書く リファインとリファクタリング したがって、最初のテストは次のようになります。 public void Returns_true_when_roll_is_full_house() { FullHouseTester sut = new FullHouseTester(); var actual = sut.IsFullHouse(1, 1, 1, 2, 2); Assert.IsTrue(actual); } 「可能な限り最も簡単なものを書く」に従っている場合、次のようにIsFullHouseメソッドを記述する必要があります。 public bool IsFullHouse(int roll1, int roll2, int roll3, int roll4, int roll5) { if (roll1 == 1 && roll2 == 1 && roll3 == 1 …

36 unit-testing  tdd 

コーディングは初めてではありません。私は今15年以上にわたって（まじめに）コーディングしてきました。私はいつも自分のコードに対していくつかのテストを行ってきました。ただし、ここ数か月にわたって、Ruby on Railsを使用してテスト駆動設計/開発（TDD）を学んでいます。これまでのところ、私は利益を見ていません。 いくつかのテストを書くことにはいくつかの利点がありますが、ごくわずかです。そして、最初にテストを書くというアイデアは好きですが、実際のコードをデバッグするよりも、テストのデバッグに時間を費やして、自分の本当の意味を伝えるようにします。これはおそらく、テストコードがテストするコードよりもかなり複雑になることが多いためです。これが利用可能なツール（この場合はRSpec）に不慣れであることを願っています。 ただし、この時点で、失望のレベルと期待を裏切るパフォーマンスの欠如が許容できないレベルを超えています。これまでのところ、TDDから私が見ている唯一の価値は、他のプロジェクト/ファイルのテンプレートとして機能するRSpecファイルの成長するライブラリです。これは実際のプロジェクトコードファイルよりもはるかに有用ではなく、おそらくあまり有用ではありません。 入手可能な文献を読むと、TDDは前もって大きな時間を費やしているように見えますが、最終的には報われます。私はただ疑問に思っています、実世界の例はありますか？この大きな不満は現実の世界で報われるのでしょうか？ ここのどこかでこの質問を見逃さなかったことを本当に願っています。検索しましたが、この時点ですべての質問/回答は数年前のものです。TDDについて悪いことを言う開発者を見つけたのはめったにありませんでした。しかし、特定の実世界の例を指し示している人はいないようです。2011年にコードをデバッグしている人は、完全な単体テストスイートを用意してくれてありがとう（コメントは2008年に作成されたと思います）という答えを1つ読みました。 だから、私は、これらすべての年月の後に、ペイオフが本物であることを示す例が最終的にありますか？TDDを使用して設計/開発され、単体テストの完全なセットを持ち、実際に見返りを感じたコードを実際に継承または戻した人はいますか？それとも、テストが何をテストしているのか（そしてなぜそれが重要だったのか）を把握しようとして非常に多くの時間を費やしていたので、コードを掘り下げて掘り下げましたか？

36 ruby-on-rails  unit-testing  tdd 

TDDを実行して単体テストを作成する場合、テストする「実装」コードの最初の反復を作成するときに、「チート」という衝動にどのように抵抗しますか。 例： 数値の階乗を計算する必要があります。次のような単体テスト（MSTestを使用）から始めます。 [TestClass] public class CalculateFactorialTests { [TestMethod] public void CalculateFactorial_5_input_returns_120() { // Arrange var myMath = new MyMath(); // Act long output = myMath.CalculateFactorial(5); // Assert Assert.AreEqual(120, output); } } このコードを実行すると、CalculateFactorialメソッドが存在しないため失敗します。そこで、テスト対象のメソッドを実装するためのコードの最初の反復を記述し、テストに合格するために必要な最小限の コードを記述します。 実は、私は次のように書き続けたいと思っています。 public class MyMath { public long CalculateFactorial(long input) { return 120; } } これは、技術的には、それで正しいです、本当に最低限のコードをするために必要とされている特定のテストパス作るそれは本当にさえいないので、それは明確に「チート」ですが、（緑行く）を試みる階乗を計算する機能を実行します。もちろん、今では、リファクタリングの部分は、実装の真のリファクタリングではなく、「正しい機能の記述」の演習になります。明らかに、異なるパラメーターで追加のテストを追加すると失敗し、リファクタリングが強制されますが、その1つのテストから開始する必要があります。 だから、私の質問は、「テストに合格するための最小限のコードを書く」ことと、機能を維持しつつ、実際に達成しようとしていることの精神とのバランスをどのように得るかということです。

36 unit-testing  tdd 

関数があるとしましょう（Rubyで書かれていますが、誰でも理解できるはずです）： def am_I_old_enough?(name = 'filip') person = Person::API.new(name) if person.male? return person.age > 21 else return person.age > 18 end end 単体テストでは、すべてのシナリオをカバーする4つのテストを作成します。それぞれはPerson::API、スタブ化されたメソッドmale?とでモックされたオブジェクトを使用しますage。 次に、統合テストを作成します。Person :: APIはもうm笑されるべきではないと思います。したがって、Person :: APIオブジェクトをモックせずに、まったく同じ4つのテストケースを作成します。あれは正しいですか？ はいの場合、単体テストを書く意味は何ですか、自信を与える統合テストを書くことができたら（スタブやモックではなく、実際のオブジェクトで作業している場合）？

36 unit-testing  testing  ruby  integration-tests