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

クラスXがあり、動作X1を検証する単体テストを作成します。Xを依存関係とするクラスAもあります。 Aの単体テストを作成するとき、Xをモックします。つまり、Aの単体テスト中に、Xのモックの動作をX1に設定（仮定）します。時間が経ち、人々はあなたのシステムを使用し、変更を必要とし、Xは進化します。Xを変更して動作X2を表示します。明らかに、Xの単体テストは失敗し、それらを調整する必要があります。 しかし、Aではどうでしょうか？Aの単体テストは、Xの動作が変更されても失敗しません（Xのモックにより）。「実際の」（変更された）Xで実行すると、Aの結果が異なることを検出する方法は？ 「それは単体テストの目的ではない」という線に沿った答えを期待していますが、単体テストにはどのような価値がありますか？すべてのテストに合格したときに、重大な変更が導入されていないことを本当に伝えているだけですか？そして、あるクラスの振る舞いが（喜んでまたは不本意で）変化するとき、どのようにすべての結果を（できれば自動化された方法で）検出できますか？統合テストにもっと集中すべきではないでしょうか？

98 unit-testing  testing  mocking 

CIサーバーで単体テストを実行するのはなぜですか？ 確かに、何かがマスターにコミットされる頃には、開発者はすでにすべての単体テストを実行し、新しいコードで発生した可能性のあるエラーを修正しています。それは単体テストのポイントではありませんか？そうでなければ、彼らは壊れたコードをコミットしたばかりです。

98 unit-testing  testing  continuous-integration  integration-tests 

私はちょうどCSの学位を取得して卒業しましたが、現在はジュニア.NET開発者（C＃、ASP.NET、およびWebフォーム）として仕事をしています。私がまだ大学にいたとき、ユニットテストの主題はカバーされましたが、その利点は実際には見られませんでした。コードのブロックが使用に適しているかどうかを判断する、つまり、何をすべきかを理解しています。しかし、私は実際に単体テストを書く必要がなかったし、その必要性を感じたこともありませんでした。 既に述べたように、私は通常ASP.NET Webフォームを使用して開発しており、最近、いくつかの単体テストを作成することを考えています。しかし、これについていくつか質問があります。 ユニットテストは、しばしば「モック」を書くことで行われることを読みました。私はこの概念を理解していますが、完全に動的なWebサイトのモックをどのように作成し、ほとんどすべてがデータベースからのデータに依存するかを理解することはできません。たとえば、私はItemDataBoundイベントなどを持っているリピーターをたくさん使用しています（これも「不明」なデータに依存します）。 質問番号1：ASP.NET Webフォームのユニットテストを書くことは頻繁に行われますが、もしそうなら：「動的環境」問題をどのように解決すればよいですか？ 私が開発しているとき、私は多くの試行錯誤を繰り返します。だからといって、自分が何をしているのかわからないというわけではありませんが、通常はコードを書いて、Ctrl F5何が起こるかを確認します。ほとんどの場合、このアプローチは仕事をしますが、時々、私は少し無知であると感じます（私の小さな経験のため）。私も時々このように多くの時間を無駄にします。 質問番号2：ユニットテストの書き始めをアドバイスしてくれませんか？実際の実装には役立つかもしれないと思いますが、それでも私は遅くなるかもしれないと感じています。

98 unit-testing  asp.net  development-process 

一部の組織では、明らかに、ソフトウェアリリースプロセスの一部は単体テストを使用することですが、どの時点でもすべての単体テストに合格する必要があります。たとえば、すべてのユニットテストが緑色で合格していることを示す画面が表示される場合があります。 個人的には、これは次の理由からそうあるべきではないと思います。 これは、コードが完璧であり、バグが存在してはならないという考えを促進します。これは、実世界ではどのようなサイズのプログラムにとっても確かに不可能です。 失敗する単体テストを考えるのは意欲をくじくものです。または、修正するのが難しい単体テストを確実に考え出してください。 いずれかの時点ですべてのユニットテストが合格した場合、その時点でのソフトウェアの状態の全体像はありません。ロードマップ/目標はありません。 実装前に、事前に単体テストを書くことを思いとどまらせます。 単体テストに失敗したソフトウェアをリリースすることも、悪いことではないことをお勧めします。少なくとも、ソフトウェアのある側面には制限があることを知っています。 ここに何かが足りませんか？組織がすべての単体テストに合格することを期待するのはなぜですか？これは夢の世界に住んでいますか？そして、それは実際にコードの本当の理解を妨げていませんか？

93 unit-testing 

私たちは約5年間生産されている大型製品に取り組んでいます。コードベースは動作しています。あまりよくありませんが、機能しています。新機能は実稼働環境に投入され、小さなQAでテストされます。バグは修正されています。しかし、私以外の誰もユニットテストを書いていません。この特別なバグ（テストケース）が二度と発生しないことを保証するために、単体テストを記述してバグを「追跡」する力を使用する人はいません。 私は経営陣と話しました。開発者と話しました。会社全体の全員と話をしました。みんな言う：「そう、もっとユニットテストを書かなければならない！」それは約一年前でした。それ以来、コミット前のコードレビュー（Gerrit）と継続的インテグレーション（Jenkins）の導入を強制しています。 ユニットテストについていくつかの会議を開催し、ユニットテストを書くことの利点も示しました。しかし、誰も興味がないようです。 Q1：同僚に単体テストを書くように動機付けるにはどうすればよいですか？ Q2：個人コードの品質基準を遵守する意欲を維持するにはどうすればよいですか？（時にはイライラすることがあります！） PS：いくつかのイライラする事実（1年で到達）： 単体テスト：1693 合計「サンプル単体テスト」：約50 完了：1521 編集：私はあまりにも期待していますか？その最初の職場であり、ベストを尽くそうとしています。 編集2：すべての答えに基づいて、私は自分のために小さなチェックリストを作成しました。私はプライベートで2人の開発者と話をしました。 そのうちの1人は、テラスティンが言ったように、彼がユニットテストに本当に不快であると私に言った。彼は「もっとプロフェッショナルになりたい」と言ったが、キックスタートが必要だ。彼はまた、すべての開発者とのユニットテスト会議（約9〜11日）は良かったと言いましたが、あまりにも混雑していました。えー 批評家もいますが、それから学びます。（tdd kataミーティングに関する以下の回答を参照してください！） もう1人は、単体テストの作成には興味がないと言いました。彼は自分の仕事が給料に十分であると考えています。彼はそれ以上の努力をしたくありません。私は全く言葉を失いました。典型的な9-5「労働者」。 来週は他の開発者と話をします。 素晴らしい回答（これまでのところ）とサポートに感謝します。ほんとうにありがとう！私は多くを学びました、ありがとうございました！

92 unit-testing  development-process  teamwork  communication 

現時点では、ユニットテストを許可するようにコード設計を変更することはコードのにおいであるのか、それともコードのにおいをせずにどの程度できるのかについて、チームで議論が行われています。これは、他のすべてのソフトウェア開発会社に存在するプラクティスを導入し始めたばかりだからです。 具体的には、非常に薄いWeb APIサービスが用意されます。その主な責任は、Web要求/応答をマーシャリングし、ビジネスロジックを含む基盤となるAPIを呼び出すことです。 1つの例は、認証方法の種類を返すファクトリの作成を計画していることです。インターフェースを継承する必要はありません。具体的なタイプ以外のものになるとは思わないからです。ただし、Web APIサービスを単体テストするには、このファクトリをモックする必要があります。 これは本質的に、（コンストラクターまたはセッターを介して）DIを受け入れるようにWeb APIコントローラークラスを設計することを意味します。つまり、DIを許可するためだけにコントローラーの一部を設計し、そうでなければ必要のないインターフェースを実装することを意味しますこの方法でコントローラーを設計する必要を避けるために、Ninjectのようなサードパーティのフレームワークがありますが、インターフェイスを作成する必要があります。 チームの何人かは、テストのためだけにコードを設計することを渋っているようです。単体テストを行うには妥協が必要だと思われますが、彼らの懸念をどのように和らげるかはわかりません。 明確にするために、これはまったく新しいプロジェクトであるため、コードを変更して単体テストを有効にすることではありません。ユニットテスト可能になるように記述するコードを設計することです。

91 unit-testing  interfaces  web-api  asp.net-core 

最近、Literate Programmingについて少し読んで、考えさせられました...よく書かれたテスト、特にBDDスタイルの仕様は、散文よりもコードが何をするかを説明するのにより良い仕事をすることができ、大きな利点があります自身の精度を検証します。 テストするコードとインラインで記述されたテストを見たことはありません。これは、言語が同じソースファイルに記述されたときにアプリケーションとテストコードを簡単に分離する傾向がないため（そして誰も簡単にしなかったため）、または人々がテストコードをアプリケーションコードから分離するより原則的な理由があるからですか？

91 testing  unit-testing  bdd  literate-programming 

次のような関数を考えてみましょう。 function savePeople(dataStore, people) { people.forEach(person => dataStore.savePerson(person)); } 次のように使用できます。 myDataStore = new Store('some connection string', 'password'); myPeople = ['Joe', 'Maggie', 'John']; savePeople(myDataStore, myPeople); 独自の単体テストがあるか、ベンダーが提供していると仮定しましょうStore。いずれにせよ、私たちは信頼していStoreます。さらに、エラー処理（たとえば、データベースの切断エラーなど）はの責任ではないと仮定しましょうsavePeople。実際、ストア自体が魔法のようなデータベースであり、何らかのエラーが発生する可能性はないと仮定しましょう。 これらの仮定を考えると、問題は次のとおりです。 savePeople()単体テストする必要がありますか、それとも組み込みのforEach言語構成のテストに相当しますか？ もちろん、モックdataStoreを渡し、dataStore.savePerson()各人に1回呼び出されることをアサートすることもできます。このようなテストは実装の変更に対するセキュリティを提供するという議論を確かに行うことができます。たとえば、forEach従来のforループや他の反復方法に置き換えることを決めた場合です。そのため、テストは完全に簡単ではありません。そしてそれでもひどく近いようです... より実りの多い別の例を次に示します。他のオブジェクトや機能を調整する以外の何もしない機能を考えてください。例えば： function bakeCookies(dough, pan, oven) { panWithRawCookies = pan.add(dough); oven.addPan(panWithRawCookies); oven.bakeCookies(); oven.removePan(); } このような機能は、どのようにユニットテストされるべきでしょうか？私は単純にモックていないユニットテストのいずれかの種類を想像するのは難しいdough、panとovenして、メソッドがそれらに呼ばれていると主張します。しかし、そのようなテストは、関数の正確な実装を複製する以上のことはしていません。 意味のあるブラックボックスの方法で関数をテストできないことは、関数自体の設計上の欠陥を示していますか？もしそうなら、どのように改善できますか？ bakeCookies例の動機となる質問をさらに明確にするために、より現実的なシナリオを追加します。これは、テストを追加してレガシーコードをリファクタリングしようとしたときに遭遇したシナリオです。 ユーザーが新しいアカウントを作成するとき、いくつかのことを行う必要があります：1）新しいユーザーレコードをデータベースに作成する必要がある2）ウェルカムメールを送信する必要がある3）ユーザーのIPアドレスを詐欺のために記録する必要がある目的。 そこで、すべての「新規ユーザー」ステップを結び付けるメソッドを作成します。 function createNewUser(validatedUserData, emailService, dataStore) …

87 unit-testing  testing  tdd 

私はこのスナフについて読みました：正当な取引が15年間テストデータと間違えられた後、Citigroupのプログラミングバグには700万ドルの費用がかかります。 システムが1990年代半ばに導入されたとき、プログラムコードは、089から100までの3桁のブランチコードが与えられたトランザクションを除外し、それらのプレフィックスをテスト目的で使用しました。 しかし1998年に、同社は事業を拡大するにつれて英数字のブランチコードの使用を開始しました。その中にはコード10B、10Cなどがあり、システムは除外範囲内にあると見なしたため、SECに送信されたレポートからそれらのトランザクションは削除されました。 （これは、非明示的なデータインジケーターを使用することは...最適ではないことを示していると思いBranch.IsLiveます。セマンティックに明示的なプロパティを設定して使用する方がはるかに良いでしょう。） それはさておき、私の最初の反応は「ユニットテストはここで助けになるだろう」でした...しかし、彼らはどうでしょうか？ 最近読んだのは、ほとんどのユニットテストがなぜ無駄なのかということでした。そのため、私の質問は次のとおりです。英数字ブランチコードの導入で失敗したユニットテストはどのようなものでしょうか。

86 unit-testing 

私のプロジェクトは、単体テストを可能にするほど十分に分離されていると思います。しかし、単体テストを価値のあるものにするために、プロジェクトは、正確に、クラスと機能の面でどれだけ大きくする必要がありますか？ 私たちは皆、間違いを犯し、完璧な人はいませんが、小さなプロジェクトのエラーをステップスルーで処理するための自分はまともなプログラマだと思います。または、プロジェクトのサイズに関係なく、単体テストは非常に必要ですか？

86 project-management  programming-practices  unit-testing  error-handling 

私は、C＃.NETで静的であるユニットテスト（モック/スタブ）依存関係に3つの方法しかないことを発見しました。 ほくろ TypeMock ジャストモック これらの2つが無料ではなく、1つがリリース1.0に達していないことを考えると、静的なものをモックするのは簡単ではありません。 それは静的な方法とそのような「悪」（ユニットテストの意味で）を作りますか？もしそうなら、なぜ再シャーパーは私に静的なもの、静的なものを作ることを望んでいますか？（再シャーパーも「悪」ではないと仮定します。） 明確化： メソッドのユニットテストを行い、そのメソッドが別のユニット/クラスで静的メソッドを呼び出す場合のシナリオについて説明しています。単体テストのほとんどの定義では、テスト対象のメソッドが他の単体/クラスの静的メソッドを呼び出すようにした場合、単体テストではなく、統合テストになります。（便利ですが、単体テストではありません。）

85 c#  unit-testing  static-methods  mocking 

複数のサブモジュールで構成されるプロジェクトのテストを書いています。作成した各テストケースは互いに独立して実行され、テスト間ですべてのデータをクリアします。 テストは独立して実行されますが、場合によっては複数のサブモジュールが必要になるため、実行順序の強制を検討しています。たとえば、サブモジュールがデータを生成し、別のサブモジュールがデータに対してクエリを実行しています。データを生成するサブモジュールにエラーが含まれている場合、サブモジュール自体が正常に機能していても、クエリサブモジュールのテストも失敗します。 私がテストしている主な機能は、最初のサブモジュールからのみデータを取得するブラックボックスリモートサーバーへの接続であるため、ダミーデータを操作することはできません。 この場合、テストの実行順序を強制してもいいですか、それとも悪い習慣ですか？このセットアップには臭いがあるように感じますが、より良い方法は見つかりません。 編集：質問は、1つのテストが別のテストのセットアップである場合のテストの構成方法からですか？「前の」テストはセットアップではなく、セットアップを実行するコードをテストするためです。

84 unit-testing  testing  patterns-and-practices 

少しのコンテキスト：今日、私は別の同僚が提供したいくつかのSQLコードを更新する必要がありました。それは非常に大きなスクリプトであるため、別個のファイルとして保存されます（その後、実行時に読み取られて実行されます）。これを行っている間に、数か月前にあった2つのバグを誤って再導入しました。 何らかの理由でASCIIファイルがUTF-16でエンコードされていました（同僚がファイルを電子メールで送信したため、ファイルが作成された可能性があります）。 スクリプトには初期SETステートメントがありませんでした（プロダクションでは一部のドライバーが必要ですが、ローカルでのクリーンインストールでは必要ありません）。 これを約1時間（再び）デバッグした後、これが二度と起こらないことを保証するためにいくつかの単体テストを書くことにしました（そして、将来の開発者に簡単な修正を提供するためにアサーションメッセージに修正する簡単な方法を含めます）。 しかし、このコードをプッシュしたとき、別の同僚（チームリーダーでもある）が近づいてきて、これらのことを二度とするべきではないと言った。 「これらのことは単体テストに属していません」 「ユニットテストは、コードのフローを確認するためにのみ使用してください」 このバグは将来再導入されないので、今やっていることは間違っていないと思うので、今はかなり対立していますが、この同僚は先輩として働いて、結局は何を決めるのですか？私たちは時間を費やしています。私は何をすべきか？このようにするのは間違っていますか？それは悪い習慣と考えられていますか？

84 unit-testing 

今日、私は「JUnitの基本」ビデオを見ていました。著者は、プログラムで特定のメソッドをテストするとき、プロセスで他のメソッドを使用しないでくださいと言いました。 具体的には、引数に名前と姓を使用するレコード作成メソッドをテストし、それらを使用して特定のテーブルにレコードを作成することについて話していました。しかし、彼は、このメソッドをテストする過程で、他のDAOメソッドを使用してデータベースにクエリを行って最終結果を確認するべきではないと主張しました（レコードが実際に正しいデータで作成されたことを確認するため）。彼は、そのために、データベースを照会して結果を確認するための追加のJDBCコードを作成する必要があると主張しました。 私は彼の主張の精神を理解していると思います：あるメソッドのテストケースが他のメソッド（この場合はDAOメソッド）の正確さに依存することは望ましくなく、これはあなた自身の検証を（再び）書くことによって達成されます/ supportingコード（より具体的で焦点が合っている必要があるため、よりシンプルなコード）。 それにもかかわらず、私の頭の中の声は、コードの重複、不必要な追加作業などの議論で抗議し始めました。他の方法をテストしながら、それらの方法の一部を使用しても大丈夫ですか？それらの1つが想定されていることを実行していない場合、独自のテストケースは失敗します。それを修正し、テストバッテリを再度実行できます。コードの複製（複製コードがいくぶん単純であったとしても）や無駄な努力は必要ありません。 私が書いたいくつかの最近のExcel - VBAアプリケーション（VBA用Rubberduckのおかげで適切にユニットテストされた）のため、私はこれについて強い気持ちがあります。 これについての洞察を共有していただけますか？

83 programming-practices  unit-testing  code-reuse 

私が理解しているように、ユニットテストのポイントは、コードのユニットを単独でテストすることです。この意味は： コードベースの他の場所にある無関係なコードの変更によって壊れてはなりません。 統合テスト（ヒープで破損する可能性がある）とは対照的に、テストされたユニットのバグによって破損するユニットテストは1つだけです。 これはすべて、テストされたユニットのすべての外部依存関係をモックアウトする必要があることを意味します。そして、ネットワーク、ファイルシステム、データベースなどの「外部レイヤー」だけでなく、すべての外部依存関係を意味します。 これは、事実上すべての単体テストがモックする必要があるという論理的な結論につながります。一方、モックに関するGoogleの簡単な検索では、「モッキングはコードのにおい」であると主張する記事が数多くあり、ほとんど（完全にではありませんが）回避する必要があります。 さて、質問へ。 ユニットテストはどのように適切に書かれるべきですか？ それらと統合テストの間の境界線は正確にどこにありますか？ アップデート1 次の擬似コードを検討してください。 class Person { constructor(calculator) {} calculate(a, b) { const sum = this.calculator.add(a, b); // do some other stuff with the `sum` } } 依存関係Person.calculateをモックせずにメソッドをテストするテストCalculator（Calculator「外の世界」にアクセスしない軽量クラスであることを考えると）は、単体テストと見なすことができますか？

80 unit-testing  testing  integration-tests  mocking  stub