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

Dogsa T、Batic Dでの以前の作業の要約を読んでいたとき、テスト駆動開発の有効性：産業のケーススタディ。ソフトウェア品質ジャーナル。2011; 19（4）：643-661。TDDに関する多くの研究で使用されている測定値は、コードの行、欠陥、開発に費やされた時間などに基づいていることが印象的でした。 TDDを使用して開発された製品と従来の開発またはテストラストを使用して開発された製品の総所有コストに焦点を当てた研究はありますか？ 私は、買収と運用の総費用に特に興味があります。

11 agile  management  tdd  computer-science 

私と私の友人は比較的新しいTDDで、「Obvious Implementation」テクニック（Kent Beckによる「TDD By Example」より）について論争しています。私の友人は、実装が明らかな場合、その新しい動作をテストする前に、先に進んでそれを書くべきだと言っています。そして実際、この本はこう言っています： 簡単な操作をどのように実装しますか？それらを実装するだけです。 また： 操作を実装する方法を知っていることが確実な場合もあります。どうぞ。 著者が意味するのは、最初にテストしてから「実装する」ことです。「フェイクイット（ 'Till You Make It）」や実装段階でより小さなステップを必要とする他のテクニックとは対照的です。また、これらの引用の後、著者は「Obvious Implementation」を行うときに「赤いバー」（テストに失敗）を取得することについて話します。テストなしで赤いバーを取得するにはどうすればよいですか。 しかし、「自明」とはまだ最初のテストを意味するという本の引用を見つけることができませんでした。 どう思いますか？実装が「自明」な場合（TDDによると）、最初にテストするか、その後にテストする必要がありますか？それを言っている本やブログの投稿を知っていますか？

11 tdd 

TDDやBDDのプロジェクトに参加したことがない、またはTDDを行っていると言っているが、それとはかなりかけ離れていると言っても、これらは私が考えていることで、できる限り読みたい約。 質問に戻ります。BDDを実行しているときは、最初に「テスト」を記述して、失敗させる必要があります。そして、その機能またはあなたがそれを呼ぶものを実装します。しかし、これを極端に考えれば、これはある種のトップダウン開発ではないでしょうか？UIを見て、「この機能/動作をここに追加したい」と言っています。次に、UIを修正して、その機能とUIをサポートするコードを実装します。この時点では、ビジネスロジックやデータアクセスロジックを実装しておらず、動作を実装しただけです。最初にテストを書く代わりに、私が目指しているのは、最初にUIコードを書くことです。UIコードを使用してビジネスでサポートする必要があるものを定義するため、場合によっては、データアクセス層とビジネス層で同じコードになるはずです。 もちろん、機能を機能で機能することを確認するために使用されるテストでこれを補完する必要があります。 何かご意見は？

11 unit-testing  tdd 

テストを書くとき、誰かがデータをモックするだけでなくインメモリデータベースを使用したいのはなぜですか？ インメモリデータベースは、自分のリポジトリをテストするのに役立つことがわかりました。ただし、フレームワーク（Spring Dataなど）を利用する場合、リポジトリのテストはフレームワークのテストであり、実際にはアプリケーションロジックではありません。 ただし、モッキングはより高速に見え、単体テストやTDDを作成するときに一般的に採用されているのと同じパターンに従っています。 それで私は何が欠けていますか？インメモリデータベースが役立つのはいつ/なぜですか？

11 unit-testing  testing  tdd  mocking 

私は1年前からTDDを行っていますが、TDDにはかなり満足しています。テストスイートなど、すべてが大好きです。しかし、最近私は多くの模擬通話検証を行っていることに気づきました。たとえば、リポジトリが挿入されるサービスがあります-単体テストでは、リポジトリのモックを渡し、テストしているメソッド内で呼び出されていることを確認します。次に、返された結果が正しいかどうかを確認します（別のテストで）。私の単体テストは実装の詳細に非常に結びついているので、これは間違いなく間違いだと感じています。「振る舞い」をテストするべきだと聞いたことがありますが、多くの状況では... emm-不可能ですか？あなたが持っている場合voidたとえば、通常は副作用をテストします。つまり、これを実証できる単純なコード型を簡単に示すことができますが、私見では、私たちが作成する実際のプログラムにはあまり反映されていません。私が間違っているのは何ですか？この種のテストは一種のアンチパターンですか？これについてのあなたの意見をいただければ幸いです。TDDに関しては、まだ初心者です。

11 unit-testing  tdd  code-smell  anti-patterns 

最近、修士プログラムのソフトウェアエンジニアリングコースの最終試験を受けましたが、試験の質問の1つは次のとおりです。 Unit Testing is considered: a. White-box Testing b. Black-box Testing c. Either 7年間のソフトウェア開発経験の中で、ユニットテストは常にホワイトボックスアプローチを採用してきました。テスターは、テストを作成する間、常にユニットの実装について完全な知識を持っています。ブラックボックステストは、統合、システム、および受け入れテストという形で常に後になります。 ただし、（教授によると）試験に対する正解は、単体テストはホワイトボックステストまたはブラックボックステストのいずれかであるということです。 私はいくつかの調査を行いましたが、多くの場合、「ブラックボックスユニットテスト」は、コードが作成される前にユニットテストが記述されるテストファーストアプローチを記述するために使用されているようです。しかし、私の意見では、これはまだホワイトボックステストです。実装はまだ存在していませんが、テストを書いている人は一般に、ソースコードの実装方法についてかなり良い考えを持っています。 ブラックボックスユニットテストのしくみ（本当にそうである場合）とホワイトボックスユニットテストとの違いを誰かに説明してもらえますか？

11 unit-testing  testing  tdd 

鶏と卵の問題のようです。 何らかのデータストアに書き込み関数を書き込むことはできますが、テスト済みの読み取り関数がなければ適切に保存したことを知ることはできません。 読み取り関数をデータストアから読み取ることができますが、テストされた書き込み関数なしで、データストアにデータを読み込むにはどうすればよいですか？ 編集： SQLデータベースに接続してトランザクションを作成し、使用するオブジェクトを保存およびロードしています。DBが提供するアクセス関数をテストする意味はありませんが、このようなDB関数をラップしてオブジェクトをシリアル化/逆シリアル化します。DBとの間で適切なものを正しく読み書きしていることを確認したいと思います。 @snowmanが言及しているように、追加/削除とは異なります。私が書いた内容が正しいことを知りたいのですが、それには十分にテストされた読み取り機能が必要です。読んだときに、書いたものと同等のオブジェクトが正しく読まれたことを確認したい。ただし、十分にテストされた書き込み関数が必要です。

10 tdd  io 

より良い解決策を見つけようとしたので、私はCodi​​lityのアルゴリズムテストに失敗し、結局何もありませんでした。 では、TDDに似たアプローチを使用できるかどうかを考えさせられました。つまり、通常は同様の方法で徐々にソリューションを開発できるか？ ソートアルゴリズムを作成している場合、標準のBubblesortから2ウェイのバブルソートに移行できますが、Quicksortのようなより高度なものは「飛躍的進歩」ですが、少なくとも簡単に検証できるテストデータがあります。 そのようなテストのための他のヒント？次回私がすることの1つは、内部ループよりも多くのメソッド/関数を使用することです。たとえば、ソートではスワップが必要になることがよくあります。メソッドの場合、呼び出しコードを変更するだけで済みます。派生クラスとして、より高度なソリューションを用意することもできます。 「アルゴリズム」と「通常」の問題では、時間の複雑さが重要な問題を意味します。そのため、TDDのようにテストに合格する代わりに、「動作が向上する」ようにします。 「TDDに似ている」とは、 手動テストの時間を節約するために、比較的自動のテストを作成します。 インクリメンタル開発。 回帰テスト、コードが壊れているかどうか、または機能がインクリメント間で変化したかどうかを検出する機能。 比較するとわかりやすいと思います シェルソートを直接書く バブルソートからクイックソートへのジャンプ（合計書き換え） 一方向のバブルソートからシェルソートに段階的に移動します（可能な場合）。

10 algorithms  tdd  self-improvement 

TDDの実行中に問題が発生。いくつかのテストに合格すると、一部のクラス/モジュールの戻り値の型が変わります。静的に型付けされたプログラミング言語で、以前にモックされたオブジェクトが他のクラスのテストで使用され、型の変更を反映するように変更されていない場合、コンパイルエラーが発生します。 ただし、動的言語の場合、戻り値の型の変更が検出されず、他のクラスのテストは引き続き成功します。もちろん、後で失敗するはずの統合テストがあるかもしれませんが、単体テストは誤ってパスします。これを回避する方法はありますか？ 簡単なサンプルで更新しています（一部の人工言語）... バージョン1： Calc = { doMultiply(x, y) {return x * y} } //.... more code .... // On some faraway remote code on a different file Rect = { computeArea(l, w) {return Calc.doMultipy(x*y)} } // test for Rect testComputeArea() { Calc = new Mock() Calc.expect(doMultiply, 2, 30) // …

10 unit-testing  mocking  tdd 

私のコードに次のような関数がある場合： class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } 通常、これをリファクタリングして、ファクトリクラスと戦略パターンを使用してPloymorphismを使用します。 public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } TDDを使用している場合は、calculateTax()リファクタリングの前にオリジナルで機能するテストをいくつか用意します。 例： calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} リファクタリング後、FactoryクラスNameHandlerFactoryと少なくとも3つのの実装ができInameHandlerます。 テストをリファクタリングするにはどうすればよいですか？の単体テストを削除して、実装ごとにTestクラスを作成する必要claculateTax()がEmployeeTestsありますInameHandlerか？ Factoryクラスもテストする必要がありますか？

10 design  design-patterns  unit-testing  tdd  refactoring 

時々、オブジェクトは密結合される必要があるだけです。たとえば、CsvFileクラスはおそらくCsvRecordクラス（またはICsvRecordインターフェイス）と緊密に連携する必要があります。 ただし、私が過去に学んだことから、テスト駆動開発の主な理念の1つは、「一度に複数のクラスをテストしないこと」です。ICsvRecordつまり、の実際のインスタンスではなく、モックまたはスタブを使用する必要がありますCsvRecord。 しかし、このアプローチを試した後、CsvRecordクラスをモックアウトすると少し毛むくじゃらになることに気づきました。これにより、2つの結論のうちの1つに導かれます。 単体テストを書くのは難しい！それはコードの匂いです！リファクタリング！ すべての依存関係をモックアウトするのは不合理です。 モックを実際のCsvRecordインスタンスに置き換えると、状況ははるかにスムーズに進みました。他の人々の考えを探しているとき、私はこのブログ投稿を偶然見つけました。これは上記の＃2をサポートしているようです。自然に密結合されているオブジェクトの場合、モッキングについてそれほど心配する必要はありません。 私は道を外れていますか？上記の仮定2の欠点はありますか？デザインをリファクタリングすることを実際に考えるべきですか？

10 tdd  coupling  mocking 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 テスト駆動開発とは、コードの前にテストを記述し、特定のサイクルを実行することを意味します。 テストを書く テストの確認（実行） 量産コードを書く テストの確認（実行） プロダクションコードのクリーンアップ テストをチェック（実行） 私に関する限り、これは、開発ソリューションでプロダクションコードとテストコードを非常に迅速に切り替え、特定のプロダクションコード部分のテストを非常に迅速に実行できる場合にのみ可能です。 今、C ++には多くの単体テストフレームワークが存在しますが（Bost.Test atmを使用しています）、TDDを作成する適切な（ネイティブC ++の）Visual Studio（Plugin）ソリューションは実際には存在しないようです。使用されるフレームワークに関係なく耐えられるサイクル。 「ベアラブル」とは、個別のテストプロジェクトなどを手動で設定しなくても、特定のcppファイルのテストを実行するのがワンクリックのアクションであることを意味します。 。 では、Visual Studioを使用したネイティブC ++開発でTDDサイクルを可能にするツール（プラグイン）とテクニックはどこにありますか？ 注：私は無料または「商用」ツールで大丈夫です。 してください：ノーフレームワーク勧告。（フレームワークに専用のVisual Studioプラグインがあり、そのプラグインを推奨する場合を除きます。） 注の編集：これまでの回答は、ユニットテストフレームワークをVisual Studioに統合する方法に関するリンクを提供しています。リソースは多かれ少なかれ、UTフレームワークをコンパイルして最初のテストを実行する方法を説明しています。これはこの質問についてではありません。ユニットテストを手動で維持（！）して実際に生産的に作業するには、vcprojを本番クラスから分離するとオーバーヘッドが大きくなり、TDDが「不可能」になると私は思います。私が知る限り、JavaまたはC＃のモノに追加の「プロジェクト」を追加してユニットテストとTDDを有効にしないでください。これは 適切なツールを与えられたC ++で可能になるが、TDD / C ++ / VS用のツールはほとんどないようです（この質問についてです）。 探し回って、正しい方向を目指しているように見えるVisualAssertというツールを見つけました。しかし、残念ながら、広く使われているようには見えません（CppUnit、Boost.Testなどと比較して）。 編集：この質問のコンテキストにコメントを追加します。問題の概要（の一部）の良い要約を示していると思います：（Billy ONealによるコメント） Visual Studioは、ユーザーが合理的に編集可能な「ビルドスクリプト」を使用しません。1つのプロジェクトで1つのバイナリが生成されます。さらに、Javaには、Javaが完全なバイナリを決して構築しないという特性があります-構築するバイナリは、クラスファイルの単なるZIPです。したがって、個別にコンパイルしてから、JARを手動で（たとえば、7zを使用して）コンパイルすることが可能です。C ++とC＃はどちらも実際にはバイナリをリンクしているため、一般的に言えば、そのようなスクリプトを作成することはできません。あなたが得ることができる最も近いのは、すべてを別々にコンパイルしてから、2つのリンクを行うことです（1つは本番用、もう1つはテスト用）。

10 ide  tdd  plugins  visual-c++ 

私は、他の多くのチームと協力して、少なくとも15年間使用されているアプリケーションを維持および改善する開発者チームの一員です。それが最初に構築および設計されたとき、TDDは前代未聞でした。 アプリケーションはかなり安定しており、番組停止のバグに遭遇することはほとんどありませんが、平均して週に1〜2件のバグがあり、サービスの品質が大幅に低下しています。これらのバグの発見と修正には、主に指差しのために永遠にかかります。私たちが行っている唯一のテストは、インターフェイステストです。バグが修正される前にバグがどこにあるかを探すのに多くの時間を費やしているため、私と別の開発者はテスト駆動開発を提案する予定です。近々新しいオーバーホールが予定されており、新しいモジュールでほぼ完全なユニットテストを実施したいと考えています。また、レガシーである変更が必要なコード（バグ修正や機能の実装など）のテストユニットの構築を提案する予定です。 ）、ただし、問題を引き起こしていないコードのテストケースの開発に時間を費やすことはできません。 私には、これは理にかなっているようです。今月は、修正に2週間以上かかるバグがありましたが、ユニットテストが行​​われていれば、導入前に特定できた可能性があります。しかし、私たちのマネージャーにとっては、彼らはより多くのお金を使うように見えるだけです。 ユニットテストとテスト駆動開発にお金を使うことをクライアントにどのように説得しますか？単体テストのROIを示す研究はありますか？

10 unit-testing  tdd 

私はTDDを勉強していますが、アプリのデザインを定義するのにも役立ちます。 それで、私はそれをよりよく理解するのを助けるために新しいプロジェクトを作り始めることにしました。 名前、メールアドレス、国（リストから1つ選択します）、電話番号を尋ねる簡単なユーザー登録システムを作成したいと考えています。 だから問題は... 私はVS 2010で新しいソリューションを作成し、新しいテストプロジェクトを追加しましたが、作成するテストがわかりません！ デザインを定義するのに役立つので、ここでどんなテストを書けますか？ 助けてくれてありがとう！

10 c#  .net  tdd 

私が理解しているように、テスト駆動開発はプログラムの仕様を定義するためのテストを書くことです（私が間違っていれば修正できます）。 ソフトウェアの仕様（パブリックAPIを含む）を作成する責任者がいる場合（彼をソフトウェアアーキテクトと呼びましょう）、それはソフトウェアアーキテクトがすべてのテストを作成する必要があることを意味しますか？ または、ソフトウェアアーキテクトが仕様を作成してから、それらを開発者に渡してテストを作成しますか？ それとも、すべての開発者が独自のテストを作成できるようにし、ソフトウェアアーキテクトの存在を忘れることによって、仕様が有機的に成長することを許可しますか？

10 architecture  tdd