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

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

410 unit-testing  tdd  builds 

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

178 unit-testing  tdd  test-automation 

トレーニングビデオで読んで見たすべての例には、単純化した例があります。しかし、グリーンになった後に「実際の」コードをどのように実行するかはわかりません。これは「リファクタリング」の部分ですか？ 複雑なメソッドを持つかなり複雑なオブジェクトがあり、テストとそれをパスするための最低限のものを書いた場合（最初に失敗した後、赤）。いつ戻って実際のコードを書きますか？そして、再テストする前に実際のコードをどれだけ書くのでしょうか？最後の方がより直感的だと思います。 編集： 答えたすべての人に感謝します。あなたの答えはすべて私を非常に助けてくれました。私が質問したり、混乱させたりしたことについては、さまざまなアイデアがあるようです。 私のデザインには、最初に作りたいアーキテクチャ、ユーザーストーリーなどがあります。ここから、それらのユーザーストーリーを取得し、ユーザーストーリーをテストするためのテストを作成します。ユーザーは、「学校に入学して登録料を支払う人がいます」と言います。だから、私はそれを失敗させる方法を考えます。そうすることで、クラスX（多分Student）のテストクラスを設計しますが、これは失敗します。次に、クラス「Student」を作成します。たぶん「学校」は分かりません。 しかし、いずれにせよ、TD デザインは私に物語を考えさせることを強いています。テストを失敗させることができる場合、失敗する理由はわかりますが、これは合格することを前提としています。それは設計についてです。 私はこれを再帰について考えることに例えました。再帰は難しい概念ではありません。実際に頭の中でそれを追跡するのは難しいかもしれませんが、実際には、最も難しいのは、再帰が「壊れる」とき、いつ停止するかを知ることです（もちろん、私の意見です）。最初に再帰。これは不完全なアナロジーに過ぎず、各再帰反復が「パス」であると想定しています。繰り返しますが、単なる意見です。 実装では、学校は見にくいです。数値および銀行台帳は、簡単な算術を使用できるという意味で「簡単」です。a + bが表示され、0などが返されます。人々のシステムの場合、それを実装する方法をより厳しく考えなければなりません。私は失敗、合格、リファクタリングの概念を持っています（主に研究とこの質問のため）。 私の知らないことは、私の意見では経験の不足に基づいています。新しい学生のサインアップに失敗する方法はわかりません。誰かが姓を入力し、データベースに保存されるのを失敗させる方法がわかりません。私は簡単な数学のためにa +1を作る方法を知っていますが、人のようなエンティティでは、誰かがデータベースまたはその両方、またはどちらでもありません。 または、これは私がまだ混乱していることを示しているかもしれません。

147 tdd 

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

139 unit-testing  tdd 

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

138 unit-testing  tdd 

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

131 unit-testing  tdd 

関数の正確な結果を事前に予測するのが難しい、非常に数値的/数学的なプログラムを頻繁に使用しています。 この種のコードで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 

私の友人と私は、統合テストとは何かを正確に分類するのに苦労してきました。 今、家に帰る途中で、統合テストの実世界の例を挙げようとするたびに、それが受け入れテストであることがわかりました。事業者が大声で言うことで、システムが何を提供すべきかを特定します。 これらのテストタイプの分類についてRuby on Railsのドキュメントを確認しましたが、今では完全にスローされています。 統合テストの簡単なアカデミックな説明を実際の例で教えてもらえますか？

110 testing  agile  tdd 

今日、同僚と興味深い議論をしました。 私は防御的なプログラマーです。「クラスは、クラスの外部から対話するときにオブジェクトが有効な状態になることを保証する必要がある」というルールを常に順守する必要があると思います。このルールの理由は、クラスがそのユーザーが誰であるかを知らず、違法な方法で対話された場合に予想通り失敗する必要があるためです。私の意見では、この規則はすべてのクラスに適用されます。 今日議論した特定の状況では、コンストラクターへの引数が正しいことを検証するコードを作成しました（たとえば、整数パラメーターは> 0でなければなりません）。前提条件が満たされない場合、例外がスローされます。一方、私の同僚は、ユニットテストがクラスの不正な使用を検出する必要があるため、このようなチェックは冗長であると考えています。さらに、彼は防御的なプログラミングの検証もユニットテストする必要があると考えているため、防御的なプログラミングは多くの作業を追加するため、TDDには最適ではありません。 TDDが防御的なプログラミングを置き換えることができるというのは本当ですか？結果としてパラメーターの検証（およびユーザー入力を意味するものではありません）は不要ですか？それとも、2つの手法は互いに補完するのでしょうか？

104 tdd  defensive-programming 

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

103 design  unit-testing  testing  tdd 

私はちょうどTDDを学んでいます。パブリックメソッドはオブジェクトの整合性を検証するのに十分な情報を提供するので、プライベートメソッドはテストできず、心配するべきではないというのが私の理解です。 私はしばらくの間OOPを理解しました。私の理解では、プライベートメソッドはオブジェクトをよりカプセル化するため、変更やエラーに対する耐性が高まります。したがって、デフォルトで使用する必要があり、クライアントにとって重要なメソッドのみを公開する必要があります。 さて、プライベートメソッドのみを持ち、イベントをリッスンすることで他のオブジェクトとやり取りするオブジェクトを作成することは可能です。これは非常にカプセル化されますが、完全にはテストできません。 また、テストのためにメソッドを追加するのは悪い習慣と考えられています。 これは、TDDがカプセル化と対立することを意味しますか？適切なバランスは何ですか？私は今、私のメソッドのほとんどまたはすべてを公開したいと思っています...

100 object-oriented  testing  tdd 

TDD体験のマイナス面は何ですか？赤ちゃんのステップ（テストをグリーンにするための最も簡単な修正）が迷惑で役に立たないと感じますか？価値のないテストを見つけますか（テストは最初は意味がありますが、最終的な実装では他のテストと同じロジックをチェックします）メンテナンスが重要ですか？等 上記の質問は、TDDの経験中に私が不快に思うことに関するものです。だから私は他の開発者が同じような感情を持っているかどうか、彼らは彼らについてどう思うか興味があります。 TDDのネガティブな側面を説明する記事へのリンクに感謝します（Googleはポジティブで熱狂的な記事でいっぱいです）。

94 tdd 

最近、テスト駆動開発（TDD）が大きくなっています。プログラマーSEやその他の会場で、さまざまな問題の解決策として推奨されることがよくあります。なぜ機能するのだろうか。 エンジニアリングの観点から見ると、2つの理由で困惑しています。 「書き込みテスト+合格するまでリファクタリングする」アプローチは、信じられないほどアンチエンジニアリングに見えます。たとえば、土木技師が橋の建設にそのアプローチを使用したり、車の車の設計者を使用すると、非常に高いコストで橋や車の形状を変更することになり、その結果、よく考え抜かれたアーキテクチャのないパッチアップされた混乱になります。「リファクタリングまでのパス」ガイドラインは、多くの場合、アーキテクチャ設計を忘れ、テストに準拠するために必要なことをすべて実行することを義務付けられています。つまり、ユーザーではなくテストが要件を設定します。このような状況で、結果の良い「虚偽」、つまり正しいだけでなく、拡張性、堅牢性、使いやすさ、信頼性、安全性、安全性などの最終結果をどのように保証できますか？これは、アーキテクチャが通常行うことです。 テストでは、システムが機能することを保証できません。そうでないことを示すだけです。言い換えれば、テストは、テストに失敗した場合にシステムに欠陥があることを示しますが、すべてのテストに合格したシステムは、テストに失敗したシステムより安全ではありません。ここでは、テスト範囲、テスト品質、およびその他の要因が重要です。「すべてがグリーン」な結果が多くの人々にもたらす誤った安全感情は、民間および航空宇宙産業では非常に危険であると報告されています。テスト戦略として」。多くの場合、テスト戦略はチェックされません。または、誰がテストをテストしますか？ 要約すると、私は「テスト」ビットよりもTDDの「ドリブン」ビットに関心があります。テストはまったく問題ありません。私が得られないのは、それを行うことで設計を推進することです。 ソフトウェアエンジニアリングのTDDが優れた実践である理由と、ソフトウェアの場合に上記で説明した問題が関連性がない（または関連性が十分でない）理由を含む回答をご覧ください。ありがとうございました。

92 testing  tdd 

私が理解している限り、ほとんどの人は、プライベートメソッドを直接テストするのではなく、パブリックメソッドを呼び出してテストする必要があることに同意しているようです。私は彼らの要点を見ることができますが、「TDDの3つの法則」に従い、「赤-緑-リファクタリング」サイクルを使用しようとすると、いくつかの問題があります。例で説明するのが一番だと思います。 現在、ファイル（タブ区切りデータを含む）を読み取り、非数値データを含むすべての列をフィルターで除外できるプログラムが必要です。おそらくこれを行うためのシンプルなツールが既にいくつか用意されていると思いますが、TDDの練習をするのにすてきできれいなプロジェクトになりそうだと思ったため、最初から実装することにしました。 したがって、最初に、「赤い帽子をかぶる」、つまり、失敗するテストが必要です。私は、行内のすべての非数値フィールドを見つけるメソッドが必要だと考えました。だから、私は簡単なテストを書いて、もちろんすぐにコンパイルに失敗するので、関数自体の記述を開始し、2、3サイクル（赤/緑）前後に作業関数と完全なテストができました。 次に、ファイルを1行ずつ読み取り、最終的に削除する必要があるすべての列を収集するために各行で「findNonNumericFields」関数を呼び出す関数「gatherNonNumericColumns」を続行します。いくつかの赤と緑のサイクルがあり、作業機能と完全なテストが完了しました。 今、私はリファクタリングする必要があると考えています。私のメソッド「findNonNumericFields」は、「gatherNonNumericColumns」を実装するときに必要だと考えたために設計されたため、「findNonNumericFields」をプライベートにするのが合理的だと思われます。ただし、テストしていたメソッドにアクセスできなくなるため、最初のテストが中断されます。 だから、私はプライベートメソッドと、それをテストするテストスイートになります。多くの人がプライベートメソッドをテストすべきでないとアドバイスしているので、私はここで一角に自分を描いたように感じます。しかし、どこで正確に失敗しましたか？ より高いレベルで始めて、最終的には私のパブリックメソッド（つまり、findAndFilterOutAllNonNumericalColumns）となるものをテストするテストを作成することもできましたが、それはTDDの全ポイントに少なくとも反すると感じます（少なくともボブおじさんによれば） ：テストと本番コードの作成を絶えず切り替える必要があります。また、任意の時点で、すべてのテストが最後の1分以内に機能しました。パブリックメソッドのテストを書くことから始めた場合、プライベートメソッドのすべての詳細が機能するようになるまでに数分（または数時間、あるいは非常に複雑な場合は数日）があり、テストがパブリックをテストするためメソッドが渡されます。 じゃあ何をすればいいの？TDD（急速な赤緑リファクタリングサイクル）は、単にプライベートメソッドと互換性がありませんか？または、私の設計に欠陥がありますか？

91 tdd  refactoring  encapsulation 

テスト駆動開発（TDD）のロンドンスタイルとシカゴスタイル（デトロイトスタイルと呼ばれることもある）について聞いてきました。 ユタ州エクストリームプログラミングユーザーグループのワークショップ： インタラクションスタイルの TDDも呼ばれmockistスタイル、またはロンドン・スタイルを、それが人気となったロンドンのエクストリーム火曜日クラブの後。通常 は、より状態ベースのデトロイトスタイルまたはクラシック TDDとは対照的です。 ジェイソン・ゴーマンのワークショップ： ワークショップでは、両方のカバーシカゴ校 TDD（状態ベースの動作テストと三角測量）、とのロンドンの学校に特に重点を置いて、からかうとエンドツーエンドのTDD、相互作用のテストにもっと焦点を当て、責任駆動設計とスティーブ・フリーマンとナット・プライスの優れた成長オブジェクト指向ソフトウェアガイド付きテスト本で最近人気を博した、OOへのアプローチをしないでください。 ポストクラシックTDDまたは「ロンドンスクール」Jason Gormanによるものは役に立ちましたが、彼の例は私を混乱させました。なぜなら、彼は両方のアプローチで1つの例の代わりに2つの異なる例を使用しているからです。違いは何ですか？各スタイルをいつ使用しますか？

88 tdd  concepts