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

私は自分のワークグループでユニットテストを提唱しようとしていますが、私がよく受ける反対意見は、外部エクスポートされたAPI（これはシステムの最小限かつ重要ではない部分のみ）にのみ使用すべきであり、内部およびプライベートでは使用しないことですコード（機能テストのみになりました）。 ユニットテストはすべてのコードに適用できるし、そうすべきだと思いますが、同僚をどのように説得できますか？

15 unit-testing 

以前、ユニットテストの経験が少しありました。（軽jor的ではなく）古典的なソフトウェアエンジニアリングプロジェクト：MVC、ユーザーGUI、データベース、中間層のビジネスロジックなど。 m C＃で科学計算ライブラリを作成する（そう、C＃が遅すぎること、Cを使用すること、車輪を再発明しないことなど）私たちはそれを必要としています）。ソフトウェア開発業界の観点から見ると、これは小さなプロジェクトです。なぜなら、私はほとんど自分で、そして時々同僚の助けを借りて書いているからです。また、私はそれに支払われません、そして最も重要なのは、学術プロジェクトです。つまり、いつかプロ品質になると期待しています。なぜなら、私はオープンソースになることを計画しているからです。 とにかく、プロジェクトは大きくなり（18,000行程度のコードで、1人のプロジェクトにとっては大きいと思います）、手に負えなくなりました。私はgitをソース管理に使用していますが、大丈夫だと思いますが、古い学校のようにテストしています。つまり、主にシステムの大部分をテストする完全なコンソールアプリケーションを作成しています。このシナリオで単体テストを行うことはできますが、それが私がやるべきことだと思います。問題は、ライブラリの大部分がアルゴリズム（たとえば、グラフアルゴリズム、分類器、数値ソルバー、ランダム分布など）であるということです。これらのアルゴリズムのそれぞれに小さなテストケースを指定する方法がわかりません。確率論的正当性を検証する方法がわかりません。たとえば、分類の場合、精度や再現率などの指標がありますが、ただし、これらのメトリックは、単一のアルゴリズムを判断するよりも2つのアルゴリズムを比較する方が適切です。だから、ここで正確さを定義するにはどうすればよいですか？ 最後に、パフォーマンスの問題もあります。まったく異なるテストセットを知っていますが、パフォーマンスは、ユーザーの満足度や他のソフトウェアエンジニアリングメトリックではなく、科学ツールの重要な機能の1つです。 私の最大の問題の1つは、データ構造にあります。kd-treeについて考えられる唯一のテストはストレステストです。大量のランダムベクトルを挿入してから、大量のランダムクエリを実行し、単純な線形検索と比較します。パフォーマンスについても同じです。数値オプティマイザーを使用すると、テストできるベンチマーク関数がありますが、これもストレステストです。これらのテストは単体テストとして分類できるとは思わず、最も重要なのは、それらのほとんどがかなり重いため、継続的に実行されることです。しかし、これらのテストを実行する必要があると思います。2つの要素を挿入してルートをポップすることはできません。はい、0-1-nの場合に機能します。 それで、もしあれば、この種のソフトウェアの（ユニット）テストアプローチは何ですか？そして、コードビルドビルドコミット統合サイクルの周りでユニットテストと重いテストをどのように整理しますか？

15 c#  unit-testing 

データベースに緊密に結合されたアプリケーションに統合されるモデルの単体テストでの最良のアプローチは何でしょうか？ ここでの特定のシナリオはショッピングカートです-カートからのアイテムの追加と削除、および価格設定ロジックなどをテストできるようにしたいと思います。データベースへのアクセスは避けてください。

15 unit-testing 

TDDの実務者から、TDDの利点の1つは開発者にSOLID原則（単一責任、オープンクローズ、Liskov置換、インターフェイス分離、依存関係反転）を強制することであると多くのことを聞きます。しかし、私にとっては、いくつかのテスト（主に単体テスト）を記述するだけで十分であり、SOLIDに従うことが重要です（したがって、テスト可能なアーキテクチャを作成します）。 TDDは、開発者に単体テストを書くよりも積極的にSOLIDをフォローするように強制しますか？

15 unit-testing  tdd  solid 

私はあなたがプライベートメソッドをテストすることになっていないことを知っています、そしてそれがあなたが必要であるように見えるなら、そこに出てくるのを待っているクラスがあるかもしれません。 しかし、パブリックインターフェイスをテストできるようにするためだけに数十億のクラスを持ちたくはありません。パブリックメソッドをテストするだけで多くの依存関係をモックする必要があり、ユニットテストは多くのクラスで行われます。巨大で追跡が難しい。 パブリックメソッドをテストする場合はプライベートメソッドをモックし、プライベートメソッドをテストする場合は外部依存関係をモックすることをお勧めします。 私は夢中ですか？

15 unit-testing  mocking 

環境： 現在、Pythonで小さなプロジェクトに取り組んでいます。私は一般的に文書化されているいくつかのパブリックメソッドで私のクラスを構造化が、主に高レベルの概念を扱う（クラスのユーザーが知っていて、使用すべきか）、そしてたくさんの隠された（アンダースコアで始まる）を担当している方法を複雑または低レベルの処理。 コードに信頼を置き、その後の変更によって以前の動作が損なわれないようにするためには、テストが不可欠であることを知っています。 問題： 信頼できるベースでより高いレベルのパブリックメソッドを構築するために、私は一般的にプライベートメソッドをテストします。コードの変更によってリグレッションが発生したかどうか、どこで発生したかを確認する方が簡単です。これは、これらの内部テストがマイナーリビジョンで壊れる可能性があり、修正/交換する必要があることを意味します しかし、私は、プライベートメソッドのユニットテストが、少なくとも異議のある概念であるか、またはより頻繁に悪い習慣と見なされていることも知っています。その理由：公の行動のみをテストする必要があります（参照） 質問： 私は次のベストプラクティスに注意を払い、理解したいと思います。 プライベート/隠しメソッドでユニットテストを使用するのはなぜ悪いのですか（リスクは何ですか）？ パブリックメソッドが低レベルおよび/または複雑な処理を使用できる場合のベストプラクティスは何ですか？ 精度： それは質問する方法ではありません。Pythonにはプライバシーの真の概念がなく、隠されたメソッドは単にリストされていませんが、名前がわかっている場合に使用できます 私はプログラミングのルールとパターンを教えたことはありません。私の最後のクラスは80年代からです...私は主に試行錯誤とインターネットでの参照によって言語を学びました（何年もの間、Stack Exchangeが私のお気に入りです）

15 python  unit-testing  methods 

私は、開発中のAPIクライアントライブラリを単体テストするための最良の方法を見つけようとして、一周して回りました。このライブラリには、Client基本的にAPIとの1：1マッピングを持つWrapperクラスと、の上部でよりユーザーフレンドリーなインターフェイスを提供する追加のクラスがありますClient。 Wrapper --> Client --> External API 私は最初の両方に対してテストの束を書いたClientし、Wrapper効果的にちょうど彼らが前方（上で動作するものは何でもの適切な機能にそのことをテストし、Wrapper上の動作Client、およびClientHTTP接続で動作します）。しかし、インターフェイスではなくこれらのクラスの実装をテストしているように感じるので、これに不快感を覚え始めました。理論的には、クラスを別の完全に有効な実装に変更することはできましたが、呼び出されると予想されていた関数が呼び出されていないため、テストは失敗します。それは私にとって脆弱なテストのように聞こえます。 この後、クラスのインターフェースについて考えました。テストでは、クラスが実際に行う方法ではなく、クラスが実際に意図したジョブを実行することを確認する必要があります。どうすればこれを行うことができますか？最初に頭に浮かぶのは、外部APIリクエストをスタブ化することです。しかし、私は外部サービスを単純​​化しすぎることに神経質です。私が見たスタブAPIの例の多くは、定型応答を提供しているだけです。これは、コードが偽のAPIに対して正しく実行されることをテストするだけの非常に簡単な方法のようです。別の方法はサービスをモックすることです。これは実行不可能であり、実際のサービスが変更されるたびに最新の状態に維持する必要があります。 最後に、私はこれを に、プログラマーSEに関する別の回答ました。 リモートAPIクライアントの仕事は、特定の呼び出しを発行することです-これ以上でもそれ以下でもありません。したがって、そのテストでは、これらの呼び出しを発行することを確認する必要があります-これ以上でもそれ以下でもありません。 そして今、私は多かれ少なかれ確信しています-テストするとき、テストClientする必要があるのは、APIへの正しいリクエストを行うことだけです（もちろん、APIが変更される可能性は常にありますが、私のテストは合格し続けます-しかしそれは統合テストが役立つ場合）。以来Clientちょうど1：APIと1のマッピング、私の懸念は実際には適用されません別の有効な実装から変更について前に-の各メソッドの唯一の有効な実装がありますClient。 しかし、私はまだにこだわっています Wrapperクラスにます。次のオプションが表示されます。 Clientクラスをスタブ化し、適切なメソッドが呼び出されることをテストします。このように、私は上記と同じClientことをしていますが、APIの代用として扱います。これは私が始めたところに私をすぐに戻します。繰り返しになりますが、これはインターフェースではなく実装のテストの不快感を与えてくれます。のWrapper非常によく、完全に別のクライアントを使用して実施することができます。 モックを作成しますClient。ここで、モックを作成する方法を決定する必要があります。サービスの完全なモックを作成するには、多くの労力が必要になります（ライブラリ自体に行った以上の作業）。API自体はシンプルですが、サービスは非常に複雑です（基本的に、そのデータに対する操作を備えたデータストアです）。そして再び、私は私のモックを本物と同期させておく必要がありますClientます。 適切なHTTPリクエストが行われていることをテストするだけです。これはWrapper、実際のClientそれらのHTTP要求を行うためにオブジェクトをため、実際に個別にテストするわけではありません。これは少しひどい単体テストになります。 したがって、これらのソリューションのいずれにも特に満足していません。あなたならどうしますか？これについて正しい方法はありますか？

14 unit-testing  testing  api  mocking  adapter 

私は現在、ファイルシステムの内容に基づいて（特に）テーブルを生成し、見つかったものに対してメタデータの変更を行うプロジェクトに取り組んでいます。問題は、これをどのようにテストするのか、セットアップするのかです。これを簡単にモックする方法はありますか？または、「サンドボックス」を設定する必要がありますか？

14 testing  unit-testing  file-handling 

データオブジェクトのコレクションを生成する方法をテスト駆動しています。オブジェクトのプロパティが正しく設定されていることを確認したい。一部のプロパティは同じものに設定されます。その他は、コレクション内での位置に依存する値に設定されます。これを行う自然な方法は、ループを使用するようです。ただし、Roy Osheroveは単体テストでロジックを使用しないことを強くお勧めします（Art of Unit Testing、178）。彼は言い​​ます： ロジックを含むテストは、通常、一度に複数のテストを行いますが、テストは読みにくく、壊れやすいため、お勧めできません。しかし、テストロジックは、隠れたバグを含む可能性のある複雑さも追加します。 テストは、一般的なルールとして、でなく、制御フローのない一連のメソッド呼び出しtry-catch、およびアサート呼び出しである必要があります。 ただし、デザインに問題はありません（データオブジェクトのリストを生成する方法はありますが、値の一部はシーケンスのどこに依存しますか？-個別に生成してテストすることはできません）。私のデザインにはテストに適さないものがありますか？または、オセロベの教えにあまりにも厳格に専念していますか？または、この問題を回避することについて私が知らない秘密のユニットテストマジックがありますか？（私はC＃/ VS2010 / NUnitで書いていますが、可能であれば言語に依存しない答えを探しています。）

14 unit-testing  loops  logic  collections 

バグを修正するには、コードのセクションを削除する必要がある場合があります。TDDの純粋主義者は、失敗したテストを記述し、コードを削除して、テストの合格を監視することを推奨します（と思います）。 さて、いくつかのコードが削除されたと断言するテストがあるのは本当に奇妙に思えます。確かに、誰もソース管理を掘り下げてそのコードを元に戻すことはないでしょうが、それだけの価値はありますか？それが価値がある場合、追加されたコードのテストを書くよりも価値が低いように見えますよね？

14 unit-testing  tdd  bug 

研究開発の仕事をしていると、私は自分の行動にある程度のランダム性があるプログラムを書いていることがよくあります。例えば、私が遺伝的プログラミングで働いているとき、私はしばしば任意のランダムなソースコードを生成して実行するプログラムを書きます。 そのようなコードのテストに関する問題は、バグが頻繁に断続的に発生し、再現が非常に困難になる可能性があることです。これは、ランダムシードを同じ値に設定して実行を開始するだけではありません。 たとえば、コードはカーネルリングバッファからメッセージを読み取り、メッセージの内容を条件付きでジャンプします。当然、後で問題を再現しようとすると、リングバッファーの状態が変更されます。 この動作は機能ですが、予期しない方法で他のコードをトリガーする可能性があるため、多くの場合、単体テスト（または人間のテスター）が見つけられないバグを明らかにします。 この種のシステムをテストするためのベストプラクティスは確立されていますか？もしそうなら、いくつかの参照は非常に役立ちます。そうでない場合は、他の提案を歓迎します！

14 testing  unit-testing  operating-systems  random 

特定のアクションの最大実行時間を指定する非機能要件があるプロジェクトでは、QAは、要件で指定されているハードウェアと負荷の両方の正確な負荷の下で、正確なハードウェアを使用して専用マシンでこのアクションのパフォーマンスを確認する必要があります。 一方、ソースコードに誤った変更を加えると、パフォーマンスに深刻な影響を与える可能性があります。早くこのマイナスの影響に着目、前のソースコードは、ソースコントロールに到達し、QA部門によって検証され、問題の報告QA部門によって失われた時間の点で有益であり、開発者が後でそれをいくつかのコミットを固定できます。 これを行うには、良いアイデアですか？ ユニットテストを使用して、同じアクション²をn回実行するのにかかった時間を把握するには、 C＃の属性を介してテストごとのタイムアウトを使用するには[TestMethod, Timeout(200)]？ このアプローチにはいくつかの問題が予想されます。 概念的には、ユニットテストは実際にはそのためのものではありません。コードのごく一部をテストするだけであり、機能要件のチェック、統合テスト、パフォーマンステストのいずれでもありません。 Visual Studioの単体テストタイムアウトは、初期化とクリーンアップがこれらのテストに存在しないか、結果に影響を与えるには短すぎることを考慮して、実際に測定されると予想されるものを測定しますか？ この方法でパフォーマンスを測定するのはいです。ハードウェア、負荷などに関係なく、任意のマシン¹でベンチマークを実行することは、あるデータベース製品が別のデータベース製品よりも常に高速であることを示すベンチマークを実行するようなものです。一方で、これらの単体テストが決定的な結果になることや、QA部門で使用されるものになることは期待していません。これらの単体テストは、期待されるパフォーマンスについての一般的なアイデアを提供するためだけに使用され、基本的に、開発者に最後の変更が何かを壊し、パフォーマンスに重大な影響を与えることを開発者に警告します テスト駆動開発（TDD）は、これらのテストでは不可能です。コードの実装を開始する前に、そもそもどのように失敗しますか？ パフォーマンステストが多すぎると、テストの実行に必要な時間に影響するため、このアプローチは短いアクションのみに制限されます。 これらの問題を考慮すると、QA部門による実際のパフォーマンスメトリックと組み合わせた場合、このような単体テストを使用することは依然として興味深いと思います。 私が間違っている？これに単体テストを使用することを完全に受け入れられないようにする他の問題はありますか？ 私が間違っている場合、ソースコードがソース管理に到達してQA部門によって検証される前に、ソースコードの変更がパフォーマンスに深刻な影響を与えたことを開発者に警告する正しい方法は何ですか？ ¹実際、ユニットテストは、同等のハードウェアパフォーマンスを備えた開発者のPCでのみ実行されることが期待されています。 ²アクションとは、実行に数ミリ秒かかるかなり短いコードのことです。

14 project-management  unit-testing  performance  requirements 

ユニットテストを始めたばかりですが、そのすべてのポイントを本当に理解しているかどうかはわかりません。チュートリアルと本をすべて読んでいますが、2つの簡単な質問があります。 ユニットテストの目的は、実際に書いたコードをテストすることだと思いました。ただし、テストを実行できるようにするには、元のコードを変更する必要があるようです。この時点では、実際に作成したコードではなく、テスト用に作成したコードをテストしています。 ほとんどのコードは外部ソースに依存しています。ただし、コードをリファクタリングすると、元のコードが破損したとしても、外部ソースはテストケース内の単なるマックアップであるため、テストは正常に実行されます。単体テストの目的に反しませんか？ ここで口がきけない場合は申し訳ありませんが、誰かが私を少し啓発できると思いました。 前もって感謝します。

14 unit-testing 

ソートされたリスト/配列の検索のような単純なものを実装しているとしましょう。関数（c＃内）は次のようになります。 static int FindIndex(int[] sortedList, int i); 機能の面でこれを実装してテストすることもできますが、明らかな理由から、通常は線形検索や意図的に愚かなものよりもバイナリ検索を好むでしょう。 だから私の質問は次のとおりです。アルゴリズムの複雑さの観点からパフォーマンスを保証するテストを作成する必要がありますか？ 私はこの質問の「あなたがすべき」部分の両側で議論を始めましたが、私はそれらを促すために私の議論なしで人々が言うことを見てみたいです。 「方法」に関しては、非常に興味深いものになります:)比較演算子をパラメーター化して、比較演算子が比較などをカウントするテストを持つことがわかります。しかし、あなたができるからといって... 他の誰かが（おそらく）これを考えましたか？ありがとう。

14 performance  unit-testing  testing 

ビデオゲームのステアリングシステムの単体テストを書いています。システムにはいくつかの動作があります（理由Aのためにこの領域を避け、理由Bのためにこの領域を避けてください。それぞれが領域のマップに少しのコンテキストを追加します。 動作の単体テストの書き方を決めるのに苦労しています。TDDが示唆しているように、私はその振る舞いが望ましい動きにどのように影響するかだけに興味があります。たとえば、avoid-because-of-reason-Aは、悪い位置を示唆する位置からの移動をもたらすはずです。実際には、ビヘイビアーがマップにコンテキストを追加する方法や理由は気にしません。目的の動きが位置から離れているだけです。 したがって、各動作のテストでは、動作を設定し、マップに書き込むようにし、マップ解析関数を実行して目的の動作を実現します。その動きが私の仕様を満たしているなら、私は幸せです。 ただし、現在のテストは、正しく動作する動作と、正しく機能するマップ解析機能の両方に依存しています。解析機能が失敗した場合、数回ではなく数百回のテストに失敗します。多くのテスト作成ガイドは、これが悪い考えであることを示唆しています。 ただし、マップをモックアウトすることで動作の出力に対して直接テストする場合、確実に実装に緊密に結合していますか？わずかに異なる動作を使用して、マップから同じ目的の動きを取得できる場合、テストは合格します。 だから今、私は認知的不協和音に苦しんでいます。これらのテストを構成する最良の方法は何ですか？

14 tdd  unit-testing