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

エンドユーザーが本番環境で深刻なバグを見つけた場合、そのバグをカバーするために失敗した単体テストを追加し、バグが修正されるまで意図的にビルドを壊すことは理にかなっています。これに対する私の論理的根拠は、ビルドがずっと失敗していたはずだったが、自動化されたテストカバレッジが不十分だったためではなかったということです。 私の同僚の何人かは、失敗した単体テストはチェックインすべきではないという意見に異議を唱えています。通常のTDDプラクティスの観点からはこの観点に同意しますが、生産バグは異なる方法で処理する必要があると思います。既知の欠陥で成功するビルド？ 他の誰かがこのシナリオを処理するための実証済みの戦略を持っていますか？意図的にビルドを壊すことは他のチームメンバーを混乱させる可能性があることを理解していますが、それはブランチの使用方法に完全に依存します。

410 unit-testing  tdd  builds 

このすばらしい投稿へのコメントで、Roy Osherove は、単一のテストで各アサートを実行するように設計されたOAPTプロジェクトについて言及しました。 以下は、プロジェクトのホームページに書かれています。 適切な単体テストは1つの理由で失敗するはずです。そのため、単体テストごとに1つのアサートを使用する必要があります。 また、ロイはコメントで次のように書いています。 私のガイドラインは、通常、テストごとに1つの論理CONCEPTをテストすることです。同じオブジェクトに複数のアサートを設定でき ます。通常、それらはテストされる同じ概念になります。 複数のアサーションが必要な場合もあると思います（例：Guard Assertion）が、一般的にはこれを回避しようとします。あなたの意見は何ですか？複数のアサートが本当に必要な実世界の例を提供してください。

397 unit-testing 

テストは、テストしている実際のコードよりもはるかに複雑で記述しにくいと感じています。テストしているコードよりもテストの作成に多くの時間を費やすことは珍しくありません。 それは正常ですか、何か間違っていますか？ 質問「単体テストまたはテスト駆動開発は価値がありますか？」、「システム自体の実装よりも機能テストの実装に多くの時間を費やしていますが、これは正常ですか？」と彼らの答えは、テストに値するかどうかについての詳細です（「テストを完全に省略する必要がありますか？」）。テストは重要だと確信していますが、実際のコードよりもテストに多くの時間を費やすのが普通なのか、それとも私だけなのか疑問に思っています。 受け取った質問の意見、回答、賛成票の数から判断すると、ウェブサイト上の他の質問では扱われていない正当な懸念があると推測できます。

211 unit-testing  testing 

私はJavaプロジェクトに取り組んでいます。ユニットテストは初めてです。Javaクラスのプライベートメソッドを単体テストする最良の方法は何ですか？

184 java  unit-testing 

私たちは、私の会社で開発者自動化テストを何度か紹介しようとしました。QAチームはSeleniumを使用してUIテストを自動化しましたが、私は常に単体テストと統合テストを導入したいと考えていました。過去に、私たちがそれを試みるたびに、皆は最初の1、2ヶ月の間興奮しました。その後、数ヶ月で、人々はそれをやめます。 いくつかの観察と質問： 自動テストは実際に機能しますか？他社で働いていた同僚のほとんどは、自動化されたテスト戦略を実装しようとして失敗しました。私はまだ実際にそれを使用し、それについて話すだけではない現実のソフトウェア会社を見ていません。多くの開発者は、自動化されたテストを理論的には素晴らしいが実際には機能しないものと見なしています。私たちのビジネスチームは、開発者が30％の余分な時間をかけてでもそれを行うことを望んでいます（少なくとも彼らはそう言っています）。しかし、開発者は懐疑的です。 自動化されたテストを適切に行う方法を実際に知っている人はいません。はい、インターネットで単体テストの例をすべて読みましたが、大きなプロジェクトにそれらを使用することはまったく別のことです。主な原因は、データベースまたはその他の重要なものをモック/スタブすることです。実際には、実際のテストを書くよりもモックに多くの時間を費やすことになります。それから、コードを書くよりもテストを書くのに時間がかかり始めたら、それはあきらめます。 複雑なデータ中心のWebアプリケーションで使用される単体テスト/システム統合テストの良い例はありますか？オープンソースプロジェクトはありますか？このアプリケーションはデータ中心ですが、ドメインロジックもたくさんあります。ある時点でリポジトリのアプローチを試してみましたが、ユニットテストにはかなり適していることがわかりましたが、データアクセスを簡単に最適化できるという代償を払って、さらに複雑な層が追加されました。 20人の経験豊富な開発者が行う大きなプロジェクトがあります。これは、単体テスト/統合テストを導入するための理想的な環境のようです。 なぜ機能しないのですか？会社でどのように機能させましたか？

178 unit-testing  tdd  test-automation 

私は、既存のアプリケーションの単体テストの作成を任されています。最初のファイルを完成させた後、元のコードの419行に対して717行のテストコードがあります。 コードカバレッジを増やすと、この比率は管理不能になりますか？ 単体テストの私の理解は、クラス内の各メソッドをテストして、すべてのメソッドが期待どおりに機能することを確認することでした。しかし、プルリクエストで、技術リーダーは、より高いレベルのテストに焦点を当てる必要があると指摘しました。彼は、各機能を徹底的にテストするのではなく、問題のクラスで最も一般的に使用される4〜5つのユースケースをテストすることを提案しました。 技術リーダーのコメントを信頼しています。彼は私よりも多くの経験があり、ソフトウェアの設計に関しては本能が優れています。しかし、このような曖昧な標準のテストを複数のチームがどのように書くのでしょうか。つまり、どのようにして仲間を知り、「最も一般的なユースケース」について同じ考えを共有しますか？ 私にとって、100％の単体テストのカバー率は高い目標ですが、50％にしか達していない場合でも、その50％の100％がカバーされていることがわかります。それ以外の場合、各ファイルの一部のテストを作成すると、多くのチートの余地が残ります。

139 unit-testing  tdd 

私は小さな会社でソロ開発者として働いています。私は実際に会社で唯一の開発者です。定期的に書いて保守しているいくつかの（比較的）大規模なプロジェクトがあり、それらをサポートするテストはありません。新しいプロジェクトを始めるとき、TDDアプローチを試してみるべきかどうかとよく疑問に思います。それは良いアイデアのように聞こえますが、私は正直に関係する余分な仕事を正当化することはできません。 私は自分のデザインを前向きに考えようと努力しています。いつか別の開発者がコードを保守するか、少なくともトラブルシューティングを行う必要があることは確かです。できる限りシンプルなものにし、把握するのが難しいものをコメントして文書化します。そして実際、これらのプロジェクトはそれほど大きくも複雑でもないので、まともな開発者は理解するのに苦労するでしょう。 私が見たテストの例の多くは、コードのすべての面をカバーする詳細にまで及びます。私が唯一の開発者であり、プロジェクト全体のコードに非常に近いので、手動で書き込みをテストするパターンに従う方がはるかに効率的です。また、要件や機能は頻繁に変更されるため、テストを維持するとプロジェクトにかなりの量のドラッグが追加されます。そうでなければビジネスニーズの解決に費やすことができる時間。 そのため、毎回同じ結論に達します。投資収益率が低すぎます。 私は時折、雇用日に基づいて誰かが会社にいた年数を計算するなど、アルゴリズムを正しく記述したことを確認するために、いくつかのテストを設定しました。しかし、コードカバレッジの観点からは、コードの約1％をカバーしています。 私の状況では、ユニットテストを定期的に行う方法をまだ見つけることができますか、それともそのオーバーヘッドを回避することを正当化できますか？ 更新： 除外した私の状況に関するいくつかのこと：私のプロジェクトはすべてWebアプリケーションです。すべてのコードをカバーするには、自動化されたUIテストを使用する必要がありますが、それは手動テストよりも大きなメリットが見られない領域です。

138 unit-testing  tdd 

私は、かなり時間に制約のある作業環境を持つソロ開発者です。開発時間は、要件、緊急度、またはその両方に応じて、プロジェクトごとに通常1〜4週間です。常に3〜4個のプロジェクトを処理していますが、一部のプロジェクトではタイムラインが重複しています。 予想通り、コードの品質が低下します。また、正式なテストも行っていません。通常、システムが多少壊れるまで、システムを歩いて行きます。その結果、かなりの量のバグが本番環境に逃げてしまいます。これを修正する必要があり、その結果、他のプロジェクトが滞ります。 これがユニットテストの出番です。正しく行われると、本番環境に逃げるバグはもちろん、バグを最小限に抑えることができます。一方、テストの作成にはかなりの時間がかかる可能性がありますが、これは私のような時間に制約のあるプロジェクトでは適切に聞こえません。 質問は、単体テスト済みのコードを未テストのコードと比べてどのくらいの時間差で書くか、そしてプロジェクトの範囲が拡大するにつれてその時間差はどのように拡大するのでしょうか？

132 unit-testing  productivity  solo-development 

現在のプロジェクト（C ++のゲーム）では、開発中にテスト駆動開発を100％使用することにしました。 コードの品質に関しては、これは素晴らしいことです。私のコードはこれほどうまく設計されていないか、バグがありません。プロジェクトの開始時に1年前に書いたコードを見るとき、私はしつこくありません。そして、より簡単にテストできるようにするだけでなく、実装と使用がより簡単になるように、物事を構造化する方法についてより良い感覚を得ました。 しかし...私がプロジェクトを始めてから1年が経ちました。確かに、空き時間にしか作業できませんが、TDDを使用すると、以前と比べてかなり遅くなります。開発の速度が遅くなると時間が経つにつれて良くなることを読み、以前よりもずっと簡単にテストを考え出すことは間違いありませんが、私は1年前からそれをやっていて、まだカタツムリのペースで働いています。 作業が必要な次のステップについて考えるたびに、毎回停止して、実際のコードを書くことができるように、テストをどのように書くかを考えなければなりません。書きたいコードを正確に知っているが、テストで完全にカバーできるほど細かく分解する方法が分からず、何時間も動けなくなることがあります。それ以外の場合は、すぐに12個のテストを考え、テストを書くのに1時間を費やして、さもなければ書くのに数分かかるであろう実際のコードの小さな断片をカバーします。 または、ゲーム内の特定のエンティティとその作成と使用のすべての側面をカバーするために50回目のテストを終了した後、To Doリストを見て、コーディングする次のエンティティを確認し、執筆の思考に恐怖を覚えます実装するための別の50の同様のテスト。 昨年の進捗状況を見ながら、「いまいましいプロジェクトを終わらせる」ためにTDDを放棄することを検討しています。ただし、付属のコード品質を放棄することは、私が楽しみにしていることではありません。テストの作成をやめると、コードをモジュール化してテストしやすくする習慣から抜け出すのが怖いです。 私はおそらくこれで非常に遅いために何か間違ったことをしていますか？メリットを完全に失うことなく生産性を向上させる代替手段はありますか？TAD？テストカバレッジが少ない？すべての生産性と動機を損なうことなく、他の人々はどのようにTDDを生き延びますか？

131 unit-testing  tdd 

配列内の要素をランダムにシャッフルする方法を検討してください。これが機能していることを確認するために、シンプルでありながら堅牢な単体テストをどのように作成しますか？ 私は2つのアイデアを思いつきましたが、どちらにも顕著な欠陥があります： 配列をシャッフルし、順序が以前と異なることを確認します。これは良いように聞こえますが、シャッフルが同じ順序でシャッフルされると失敗します。（ありえませんが、可能です。） 一定のシードで配列をシャッフルし、所定の出力に対してチェックします。これは、同じシードが与えられると常に同じ値を返すランダム関数に依存しています。ただし、これは無効な仮定である場合があります。 サイコロの出目をシミュレートし、乱数を返す2番目の関数を考えます。この機能をどのようにテストしますか？その機能をどのようにテストしますか... 与えられた範囲外の数値を返すことはありませんか？ 有効な分布で数値を返しますか？（1つのダイスで均一、多数のダイスで通常）。 これらの例だけでなく、一般的なコードのランダム要素をテストするための洞察を提供する回答を探しています。ユニットテストはここでも正しい解決策ですか？そうでない場合、どのようなテストがありますか？ みんなの心を楽にするためだけに、私は自分の乱数ジェネレーターを書いていません。

127 testing  unit-testing  random 

関数の正確な結果を事前に予測するのが難しい、非常に数値的/数学的なプログラムを頻繁に使用しています。 この種のコードでTDDを適用しようとすると、そのコードの単体テストを書くよりもテスト対象のコードを書く方がはるかに簡単だと思うことがよくあります。期待される結果を見つける唯一の方法は、アルゴリズム自体を適用することです頭の上、紙の上、またはコンピューターで）。これは間違っていると感じます。なぜなら、テスト中のコードを効果的に使用して、単体テストを検証するためであり、その逆ではありません。 テスト対象のコードの結果を予測することが困難な場合に、単体テストを作成し、TDDを適用するための既知の技術はありますか？ 結果を予測するのが難しいコードの（実際の）例： 機能weightedTasksOnTime日あたりの仕事量が与えられると、workPerDay範囲（0、24]、現在時刻initialTime> 0、およびタスクのリストtaskArrayプロパティ完了するまでの時間と各; time> 0、期日due、及び重要度をimportance、リターン彼らの前に完了することができるタスクの重要性を示す範囲[0、1]に正規化された値dueの各タスクは、場合によって与えられた順序で完了した場合、日付taskArrayから開始し、initialTime。 この関数を実装するアルゴリズムは比較的簡単です：でタスクを繰り返しtaskArrayます。各タスクについて、に追加timeしinitialTimeます。新しい時間<の場合、アキュムレーターdueに追加importanceします。時間は逆workPerDayによって調整されます。アキュムレータを返す前に、タスクの重要度の合計で除算して正規化します。 function weightedTasksOnTime(workPerDay, initialTime, taskArray) { let simulatedTime = initialTime let accumulator = 0; for (task in taskArray) { simulatedTime += task.time * (24 / workPerDay) if (simulatedTime < task.due) { accumulator += task.importance } } return accumulator / totalImportance(taskArray) } 上記の問題は、コアを維持しつつworkPerDay、正規化要件を削除することで単純化できると考えています。 …

124 unit-testing  tdd 

私は大学を卒業したばかりで、来週どこかで大学を始めています。単体テストを見てきましたが、あまり使用しませんでした。誰もがそれらについて話すので、私はいくつかのことをすべきだと思いました。 問題は、何をテストすべきかわからないことです。一般的なケースをテストする必要がありますか？エッジケース？機能が適切にカバーされていることを知るにはどうすればよいですか？ 特定のケースで機能が機能することをテストで証明することはできますが、機能が機能することを証明することはまったく役に立たないという恐ろしい気持ちが常にあります。

122 unit-testing  testing  test-coverage 

一部の人々は、統合テストはすべての種類の悪い点と間違っていると主張しています -すべてを単体テストする必要があります。さまざまな理由で、私は常に好きではないオプション。 場合によっては、単体テストでは何も証明されないことがわかります。 例として、次の（PHPでの）単純な（単純な）リポジトリー実装を取り上げましょう。 class ProductRepository { private $db; public function __construct(ConnectionInterface $db) { $this->db = $db; } public function findByKeyword($keyword) { // this might have a query builder, keyword processing, etc. - this is // a totally naive example just to illustrate the DB dependency, mkay? return $this->db->fetch("SELECT * …

120 unit-testing  testing  integration-tests  repository-pattern 

私は自分のコードで定期的にユニットテストを書く習慣を身につけようとしていますが、最初に読んだのはテスト可能なコードを書くことです。 この質問は、テスト可能なコードを作成するという固い原則に触れていますが、テストの作成をまったく計画せずに、それらの設計原則が有益である（少なくとも害がない）かどうかを知りたいです。明確にするために-テストを書くことの重要性を理解しています。これは、それらの有用性に関する質問ではありません。 私の混乱を説明するために、この質問に影響を与えた作品で、ライターは現在の時刻をチェックし、時刻に応じて値を返す関数の例を示します。作成者は、内部で使用するデータ（時間）を生成するため、テストが困難になるため、これを不良コードと指摘します。私にとっては、しかし、引数として時間を渡すことはやり過ぎのようです。ある時点で、値を初期化する必要がありますが、なぜ消費に最も近いのではありませんか？さらに、私の考えでは、このメソッドの目的は、現在の時刻に基づいて何らかの値を返すことであり、この目的を変更できるかどうかを示すパラメータにすることです。これと他の質問は、テスト可能なコードが「より良い」コードと同義語かどうか疑問に思います。 テストがない場合でも、テスト可能なコードを書くことはまだ良い習慣ですか？ テスト可能なコードは実際にはより安定していますか？重複として提案されています。ただし、その質問はコードの「安定性」に関するものですが、読みやすさ、パフォーマンス、結合など、他の理由でもコードが優れているかどうかについてより広くお尋ねしています。

103 design  unit-testing  testing  tdd 

自動化されたテストの価値を理解し、問題が十分に特定されていて、良いテストケースを思いつくことができる場所ならどこでもそれを使用します。ただし、こことStackOverflowの一部の人々は、依存関係ではなくユニットのみをテストすることを強調していることに気付きました。ここでは、利益が見られません。 テストの依存関係を回避するためのモッキング/スタブ化は、テストを複雑にします。実稼働コードに人為的な柔軟性/デカップリング要件を追加して、モックをサポートします。（これは良いデザインを促進すると言う人には賛成できません。余分なコードを書いたり、依存性注入フレームワークのようなものを導入したり、コードベースに複雑さを加えて実際のユースケースなしで物事をより柔軟/プラグ可能/拡張可能/分離することは、オーバーエンジニアリングではなく、良いデザイン。） 第二に、依存関係のテストとは、どこでも使用される重要な低レベルコードが、テストを明示的に考えた人以外の入力でテストされることを意味します。依存する低レベルの機能をモックアウトせずに、高レベルの機能で単体テストを実行することで、低レベルの機能に多くのバグを発見しました。理想的には、これらは低レベル機能の単体テストで発見されたはずですが、見逃されたケースは常に発生します。 これの反対側は何ですか？単体テストが依存関係もテストしないことは本当に重要ですか？もしそうなら、なぜですか？ 編集：データベース、ネットワーク、Webサービスなどの外部依存関係のモックの価値を理解できます（これを明確にする動機付けをしてくれたAnna Learに感謝します）。内部依存関係、つまり他のクラス、静的関数などに言及していました。直接的な外部依存関係はありません。

103 testing  unit-testing  dependency-injection  mocking