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

リストで期待されていることを関数が実行することをテストしています。だから私はテストしたい f(null) -> null f(empty) -> empty f(list with one element) -> list with one element f(list with 2+ elements) -> list with the same number of elements, doing what expected そうするために、最善のアプローチは何ですか？ 「WorksAsExpected」という名前で、同じ（メソッド）テストですべてのケースをテストする 各ケースに1つのテストを配置し、こうして 「WorksAsExpectedWhenNull」 「WorksAsExpectedWhenEmpty」 「WorksAsExpectedWhenSingleElement」 「WorksAsExpectedWhenMoreElements」 私が考えていなかった別の選択肢:-)

21 unit-testing  tdd 

私は最近、C＃での関数型プログラミングというタイトルの本を読んでいます。関数型プログラミングの不変でステートレスな性質は、依存性注入パターンと同様の結果を達成し、特にユニットテストに関してはより良いアプローチである可能性があります。 両方のアプローチの経験がある人なら誰でも、主な質問に答えるために自分の考えや経験を共有できれば感謝しています。

21 design-patterns  unit-testing  functional-programming  dependency-injection 

開発者からの優れたユニットテストがないことの主な言い訳は、「コードはユニットテスト可能な方法で設計されていない」です。ユニットテストできないデザインとコードの種類を理解しようとしています。

21 unit-testing 

いくつかのHadoop Webサービスを呼び出すクラスをテストしようとしています。コードはほぼ次の形式です。 method() { ...use Jersey client to create WebResource... ...make request... ...do something with response... } たとえば、ディレクトリ作成メソッド、フォルダ作成メソッドなどがあります。 コードが私が制御できない外部Webサービスを処理していることを考えると、これをどのように単体テストできますか？Webサービスのクライアント/レスポンスをモックすることはできましたが、最近見た「所有していないオブジェクトをモックしないでください」というガイドラインに違反しています。ダミーのWebサービス実装をセットアップできます。それでも「単体テスト」を構成できますか、それとも統合テストになりますか？この低いレベルで単体テストを実行することはできませんか？TDD実践者はどのようにこれに取り組むのでしょうか？

21 unit-testing  tdd  web-services  integration-tests 

私は、チームで実装しているユニットテストに関して、ますます厄介な問題に取り組んでいます。うまく設計されていないユニットコードをレガシーコードに追加しようとしていますが、実際にテストを追加するのに苦労することはありませんが、テストの結果に苦労し始めています。 問題の例として、実行の一部として5つの他のメソッドを呼び出すメソッドがあるとしましょう。このメソッドのテストは、これらの5つのメソッドのいずれかが呼び出された結果として動作が発生することを確認することです。そのため、単体テストは1つの理由と1つの理由でのみ失敗するはずなので、これらの他の4つのメソッドを呼び出して発生する潜在的な問題を排除し、それらをモックアウトする必要があります。すばらしいです！単体テストが実行され、モックされたメソッドは無視され（その動作は他の単体テストの一部として確認できます）、検証が機能します。 しかし、新しい問題があります-単体テストには、今後、他の4つのメソッドのいずれかに対する動作とシグネチャの変更、または「親メソッド」に追加する必要のある新しいメソッドの確認方法に関する詳細な知識があります。失敗の可能性を回避するために、単体テストを変更する必要があります。 当然のことながら、より多くのメソッドがより少ない動作を達成するようにするだけで、問題を多少軽減できますが、おそらくよりエレガントなソリューションが利用できることを望んでいました。 問題をキャプチャする単体テストの例を次に示します。 簡単なメモとして、「MergeTests」は単体テストクラスであり、テストしているクラスから継承し、必要に応じて動作をオーバーライドします。これは、外部クラス/依存関係への呼び出しをオーバーライドできるようにするためにテストで使用する「パターン」です。 [TestMethod] public void VerifyMergeStopsSpinner() { var mockViewModel = new Mock<MergeTests> { CallBase = true }; var mockMergeInfo = new MergeInfo(Mock.Of<IClaim>(), Mock.Of<IClaim>(), It.IsAny<bool>()); mockViewModel.Setup(m => m.ClaimView).Returns(Mock.Of<IClaimView>); mockViewModel.Setup( m => m.TryMergeClaims(It.IsAny<Func<bool>>(), It.IsAny<IClaim>(), It.IsAny<IClaim>(), It.IsAny<bool>(), It.IsAny<bool>())); mockViewModel.Setup(m => m.GetSourceClaimAndTargetClaimByMergeState(It.IsAny<MergeState>())).Returns(mockMergeInfo); mockViewModel.Setup(m => m.SwitchToOverviewTab()); mockViewModel.Setup(m => m.IncrementSaveRequiredNotification()); mockViewModel.Setup(m => …

21 c#  testing  unit-testing  mocking 

私はTDDの意味でのユニットテストについて話している。（自動化された「統合」ではなく、テストと呼ぶのが好きです。） レガシーコード：（C ++）テストなしのコード。（参照：マイケルフェザーズのレガシーコードでの効果的な作業） しかし、次のようなレガシーコード：私たちのチームが過去10〜5年間作業してきたコードです。そのため、何かを変更するためにどこに置くべきかについて非常によく考えています。 私たちは何のために（Boost.Test経由）の場所でのユニットテスト持ち、いくつかの後に来たか、ユニットテストのための「自然な」フィットされているモジュール（一般的なアプリの特定のコンテナ、文字列のもの、ネットワークヘルパーなど） 適切な自動受け入れテストはまだありません。 さて、最近、3つの新しいユーザー向け機能を実装する「喜び」がありました。 それらのそれぞれは、私が変更するのに必要なコード部分に慣れるのに約1〜2時間、変更するのに必要な（小さな）コードを実装するのに1〜2時間、そしてアプリを確認するのにさらに1〜2時間かかりましたその後正しく実行され、実行するはずでした。 今、私は本当に小さなコードを追加しました。（各機能に対して1つのメソッドといくつかの呼び出し行があると思います。） このコードを（WEwLCで提案されている方法のいずれかを介して）除外するので、単体テストが理にかなっている（完全なトートロジーではない）ために、さらに2〜4時間は簡単にかかっていました。これにより、各機能に50％〜100％の時間が追加され、すぐにメリットは得られません。 コードについて何かを理解するのに単体テストは必要ありませんでした コードがアプリの他の部分に正しく統合されているかどうかをテストする必要があるため、手動テストは同じ量の作業です。 確かに、あれば、後に、「誰かが」に沿って来て、そのコードに触れ、彼は理論的には、そのユニットテストからいくつかの利点を持つことができます。（テストされたコードの島はテストされていないコードの海に住んでいるので、理論的にのみ。） したがって、「今回」は、ユニットテストを追加するというハードワークを行わないことを選択しました。テスト対象のものを取得するためのコード変更は、機能を正しく（そしてクリーンに）実装するためのコード変更よりもはるかに複雑でした。 これは、強く結合されたレガシーコードの典型的なものですか？私は怠け者ですか/チームとして間違った優先順位を設定していますか？または、オーバーヘッドが高すぎないものだけをテストするのが賢明ですか？

21 c++  tdd  legacy  unit-testing 

私がキャリアで出くわした繰り返しのテーマは、チームに到着する新しい開発者であること、そして既存のユニットと統合テストスイートに対する固有の不信をすぐに持つことです。 面接中に、経営陣から「ユニットテストを強力にサポートしている」ことと、それを公然と奨励していることが伝えられます。彼らはそうしますが、テスト自体についてのすべては単に間違っています。100％の統合テストカバレッジがあり、10％未満の反復可能な単体テストカバレッジがある場合、100％のカバレッジを主張しているという事実と同様です。私が見つけた他のいくつかの問題： 単体テストと統合テストの間に明確な兆候はありません。単体テストと統合テストは、同じクラスに混在しています。 特定の環境のデータベース上の非常に特定の動的データに対する未宣言の明示的な依存関係がある統合テスト。 非トランザクション統合テスト。基本的には、後からクリーンアップするかどうかわからないテストであり、テストを再現可能にするために手動のデータベース「スクラビング」が必要になる場合があります。 モッキングは一切行われません。アプリケーションコードでは、モッキングを可能にするためだけに大幅な見直しが必要です。つまり、テストを考慮せずに設計します。 テスト名をすばやく確認して、実行中のテストを大まかに判断するための明確な命名規則はありません。 これは、すべてのテストが役に立たないか悪いというわけではなく、かなりの数のテストが非常に良く、維持する価値があると言っているわけではありませんが、金のためにパンするような気がします。ブラックボックステストケースのデータベースを台無しにするのが怖かったからといって、意図的にテストを実行することは避けました。 これは本質的に、私が個人的に何らかの方法で書いたりレビューしたりしていないユニットおよび統合テストの固有の不信感を与えました。あるレベルでは、テストスイートの品質を信頼していない場合、チームやプロジェクトにはまったく価値がありません。 この状況に陥ったとき、あなたはどうしますか？攻撃の最善の計画は、このようなものに取り組むことだと思いますか？ すべてのテストをリリース間で途方もない努力でリファクタリングする必要がありますか？このレガシープロジェクトが1日の強固な単体テストの対象となる可能性があるという考えを捨てる必要がありますか？

21 unit-testing  team  refactoring  bad-code  integration-tests 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 ワークグループにユニットテストを導入するための戦いでは、この概念についてほとんど知識を持たない人がたくさんいます。提案できますか： トピックに関する人々を迅速に紹介するための最高の記事またはチュートリアル ユニットテストを詳細に学習するための最高の包括的な本 ユニットテストの有効性を証明する学術研究と研究

21 books  testing  unit-testing 

TDDに関するテキストでは、リファクタリングのステップ中に「重複の削除」または「読みやすさの向上」についてよく読みます。しかし、未使用の関数を削除する理由は何ですか？ たとえばC、メソッドa()とを持つクラスがあるとしましょうb()。今私はそれにf()追いやられる方法を持つことが良いと思うC。実際、定義/記述された単体テストを除くf()すべての呼び出しを置き換えます。これはもう必要ありません-テストを除いて。b()b() 削除してb()、それを使用したすべてのテストを削除するだけでいいですか？その部分は「読みやすさの改善」ですか？

20 unit-testing  refactoring  tdd  readability 

テストと実際のコード間でデータを複製するのは良いですか、悪いですか？たとえば、FooSaver特定の名前のファイルを特定のディレクトリに保存するPythonクラスがあるとします。 class FooSaver(object): def __init__(self, out_dir): self.out_dir = out_dir def _save_foo_named(self, type_, name): to_save = None if type_ == FOOTYPE_A: to_save = make_footype_a() elif type == FOOTYPE_B: to_save = make_footype_b() # etc, repeated with open(self.out_dir + name, "w") as f: f.write(str(to_save)) def save_type_a(self): self._save_foo_named(a, "a.foo_file") def save_type_b(self): self._save_foo_named(b, "b.foo_file") 私のテストでは、これらのファイルがすべて作成されたことを確認したいので、次のように言いたいと思います。 …

20 unit-testing  coding-style  clean-code 

私のドメインは、次のような多くの単純な不変のクラスで構成されています。 public class Person { public string FullName { get; } public string NameAtBirth { get; } public string TaxId { get; } public PhoneNumber PhoneNumber { get; } public Address Address { get; } public Person( string fullName, string nameAtBirth, string taxId, PhoneNumber phoneNumber, Address address) { if (fullName …

20 c#  unit-testing 

バックグラウンド テスト駆動開発は、私がすでに学校を卒業した後、業界で普及しました。私はそれを学ぼうとしていますが、いくつかの大きな事柄がまだ私を逃れています。TDDの支持者は、次のような多くのことを言います（以降、「単一アサーション原則」またはSAPと呼びます）。 しばらくの間、TDDテストを可能な限りシンプルで表現力豊かでエレガントにする方法について考えてきました。この記事では、テストをできる限り単純かつ分解したものにすることについて、各テストで単一のアサーションを目指して少し探ります。 ソース：http : //www.artima.com/weblogs/viewpost.jsp?thread=35578 彼らはまた、このようなことを言います（以下「プライベートメソッドの原則」またはPMPと呼ばれます）： 通常、プライベートメソッドを直接単体テストすることはありません。これらはプライベートなので、実装の詳細と考えてください。誰もそれらのいずれかを呼び出して、特定の方法で動作することを期待することはありません。 代わりに、パブリックインターフェイスをテストする必要があります。プライベートメソッドを呼び出すメソッドが期待どおりに機能している場合、拡張機能によってプライベートメソッドが正常に機能していると想定します。 ソース：プライベートメソッドを単体テストする方法 状況 ステートフルデータ処理システムをテストしようとしています。システムは、データを受け取る前の状態を考えると、まったく同じデータに対して異なることを行うことができます。システムに状態を​​構築し、特定のメソッドがテストすることを意図した動作をテストする簡単なテストを検討してください。 SAPは、「状態ビルドアッププロシージャ」をテストするべきではないことを提案します。状態はビルドアップコードから予想されるものであると想定し、テストしようとしている1つの状態変化をテストします。 PMPは、この「状態構築」ステップをスキップして、その機能を独立して制御するメソッドをテストすることはできないことを示唆しています。 私の実際のコードの結果は、肥大化し、複雑で、長く、書くのが難しいテストです。状態遷移が変更された場合、テストを変更する必要があります...これは、小さく効率的なテストでは問題ありませんが、これらの長い肥大したテストとは非常に時間がかかり、混乱を招きます。これは通常どのように行われますか？

20 design  unit-testing  tdd 

TDDアプローチを使用することを自分で学びたいと思っていたので、しばらくの間、やりたいプロジェクトがありました。大規模なプロジェクトではなかったので、TDDの良い候補になると思いました。しかし、何かがおかしくなったように感じます。例を挙げましょう： 高レベルでは、私のプロジェクトはMicrosoft OneNoteのアドインであり、プロジェクトをより簡単に追跡および管理できます。また、いつか自分のカスタムストレージとバックエンドを構築することにした場合に備えて、このためのビジネスロジックをOneNoteから可能な限り切り離したままにしておきたいと考えました。 最初に、基本的な平易な言葉の受け入れテストから始めて、最初の機能で何をしたいかを概説しました。これは次のようなものです（簡潔にするために説明を省略しています）。 ユーザーがプロジェクトの作成をクリックします プロジェクトのタイトルにユーザーが入力する プロジェクトが正しく作成されたことを確認します UIのものといくつかの中間計画をスキップして、最初のユニットテストに行きます。 [TestMethod] public void CreateProject_BasicParameters_ProjectIsValid() { var testController = new Controller(); Project newProject = testController(A.Dummy<String>()); Assert.IsNotNull(newProject); } ここまでは順調ですね。赤、緑、リファクタリングなど。今では実際に保存する必要があります。ここでいくつかの手順を省略して、これで終わります。 [TestMethod] public void CreateProject_BasicParameters_ProjectMatchesExpected() { var fakeDataStore = A.Fake<IDataStore>(); var testController = new Controller(fakeDataStore); String expectedTitle = fixture.Create<String>("Title"); Project newProject = testController(expectedTitle); Assert.AreEqual(expectedTitle, newProject.Title); } …

20 c#  agile  unit-testing  tdd  refactoring 

TL; DR 優れた有用なテストを書くのは難しく、C ++でのコストは高くなります。経験豊富な開発者は、何をいつテストするかについての論理的根拠を共有できますか？ 長い話 私はチーム全体でテスト駆動開発を行っていましたが、実際にはうまくいきませんでした。多くのテストがありますが、実際のバグやリグレッションがあるケースをカバーすることはないようです-通常、ユニットが相互作用しているときに発生し、孤立した動作からではありません。 これは多くの場合、ユニットレベルでテストするのが非常に難しいため、TDDの実行を停止し（開発を実際にスピードアップするコンポーネントを除く）、代わりに統合テストの対象範囲を増やすためにより多くの時間を費やしました。小規模なユニットテストは実際のバグをキャッチすることはなく、基本的にメンテナンスオーバーヘッドにすぎませんでしたが、統合テストは本当に努力する価値がありました。 今、私は新しいプロジェクトを継承しましたが、それをテストする方法を知りたいと思っています。ネイティブのC ++ / OpenGLアプリケーションであるため、統合テストは実際にはオプションではありません。しかし、C ++でのユニットテストはJavaよりも少し難しく（明示的にものを作成する必要がありますvirtual）、プログラムはオブジェクト指向ではないため、いくつかのものをモック/スタブすることはできません。 テストを書くためにいくつかのテストを書くためだけに、すべてを引き裂いてオブジェクト指向化したいとは思いません。だから私はあなたに尋ねています：それは何のためにテストを書くべきですか？例えば： 頻繁に変更する予定の関数/クラス 手動でテストするのがより難しい関数/クラス？ すでにテストが簡単な関数/クラス？ 敬意を表するいくつかのC ++コードベースを調べて、テストがどのように行われるかを確認し始めました。今はChromiumのソースコードを調べていますが、コードからテストの理論的根拠を抽出するのは難しいと感じています。人気のあるC ++ユーザー（委員会、本の著者、Google、Facebook、Microsoftなど）がこれにどのようにアプローチしているかについて、良い例や投稿がある場合は、さらに役立つでしょう。 更新 これを書いて以来、私はこのサイトとウェブを探索しました。良いものを見つけました： 単体テストを行わないのはいつが適切ですか？ /programming/109432/what-not-to-test-when-it-comes-to-unit-testing http://junit.sourceforge.net/doc/faq/faq.htm#best 悲しいことに、これらはすべてJava / C＃中心です。Java / C＃で多くのテストを作成することは大きな問題ではないため、通常は利益がコストを上回ります。 しかし、上で書いたように、C ++ではより困難です。特に、コードベースがそれほどオブジェクト指向でない場合は、ユニットテストのカバレッジを良好にするために、物事をひどく混乱させる必要があります。例えば、私が継承したアプリケーションにGraphicsは、OpenGLの上にある薄層の名前空間があります。すべてのエンティティをテストするには、すべてのエンティティがその機能を直接使用するため、これをインターフェイスとクラスに変換し、すべてのエンティティに挿入する必要があります。それはほんの一例です。 したがって、この質問に答えるとき、テストを書くためにかなり大きな投資をしなければならないことに注意してください。

20 c++  unit-testing  tdd  integration-tests 

私は最近、時系列が本質的にある時系列モジュールを設計しましたSortedDictionnary<DateTime, double>。 次に、このモジュールが常に機能し、期待どおりの結果が得られることを確認するための単体テストを作成します。 一般的な操作は、時系列のポイント間のパフォーマンスを計算することです。 したがって、私が行うことは、たとえば{1.0、2.0、4.0}（いくつかの日付）で時系列を作成することであり、結果は{100％、100％}になると予想しています。 問題は、値{1.0、1.0}を使用して時系列を手動で作成し、（各ポイントを比較することにより）等しいかどうかを確認すると、実数のバイナリ表現で作業するときは常に不正確になるため、テストは合格しません数字。 したがって、次の関数を作成することにしました。 private static bool isCloseEnough(double expected, double actual, double tolerance=0.002) { return squaredDifference(expected, actual) < Math.Pow(tolerance,2); } そのような場合に対処する別の一般的な方法はありますか？

20 .net  unit-testing  numbers