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

ユニットテストは、ソースコードの個々のユニットをテストして、それらが使用に適しているかどうかを判断する方法です。

3
別の品質保証(QA)の完全に重複したシステムを作成することは悪い習慣ですか?
職場では、かなり複雑なシステムがあります。このシステムをSystem_Aと呼びます。QAチームは別のシステムを作成しました。このシステムをSystem_Bと呼び、System_Aをテストします。 System_Bの使用方法は次のとおりです。入力(System_B自体を使用)INを生成し、そのような入力をSystem_Bを介して処理し、出力O_Bを生成します。したがって、プロセスは次のとおりです。 System_B(IN) -> O_B。 次に、System_Aにも同じことを行い、独自の出力O_Aを生成します。 System_A(IN) -> O_A。 いつでも、O_Bは期待される出力であり、O_Aは観測された/実際の出力であると想定されます。暗黙のうちに、O_Bは「ゴールド」ソース(真実)です。しかし、問題の組み合わせに遭遇しました。 O_Aは間違っている、O_Bは正しい O_Aは正しい、O_Bは正しい O_Aが間違っている、O_Bが間違っている O_Aは正しい、O_Bは間違っている O_Bが常に正しいと想定されている場合(または何が期待されている場合)、何が正しいかをだれが決定しますか まあ、それはO_Bが人間の検査と分析で時々(またはしばしば)間違っていることがわかりました。物事はこのプロセスを使用してQAに合格し、実際のユーザーは不満を抱きます。結局、O_Bが間違っていたことが判明するまで戻ります。 問題はこれです。実際のシステムをテストするための「テストシステム」を作成することは悪い習慣ですか? 滑りやすい斜面はどうですか?それでは、「テストシステム」をテストするためにさらに別のシステムが必要だと主張できないでしょうか。 開発者は少なくとも2つのコードベースを学習する必要があり、おそらくSystem_BはSystem_Aよりも複雑であるため、コストは明らかに法外です。System_Bが組織にとってどれほど良いか悪いかをどのように定量化しますか? System_Bを作成する本来の「説得力のある」理由の1つは、テストを「自動化」することでした。現在、完全に自動化されていることを非常に誇りに思っています(System_Bが入力を生成して、それ自体を使用して出力も生成するプロセスをブートストラップするため)。しかし、定量化できない方法で、より多くの危害を加え、より複雑さを導入したと思います。QAの仕事は完全に自動化されていますか?その理由は、並列システムを作成することを正当化するのに十分ですか? 私の本当の懸念はこれです。System_Bが間違っていることは誰もが知っています(かなり頻繁に)。System_Bが入力の処理に非常に優れていて、その出力がゴールドソースである場合は、System_AをSystem_Bに置き換えてみませんか?それに対して、職場の誰も満足のいく対応をすることができません。 この問題に関するガイダンスは大歓迎です。

2
単体テストと統合テストのコードカバレッジレポートを分けますか、それとも両方のレポートを1つにしますか?
単体テストと統合テストの個別のコードカバレッジレポート、または両方のコードカバレッジレポートが必要ですか? この背後にある考え方は、コードカバレッジにより、コードが可能な限りテストによってカバーされていることを確認できるということです(とにかく、マシンができる限り)。 個別のレポートがあると、単体テストでカバーされなかったこと、統合テストでカバーされなかったことを知るのに便利です。しかし、この方法では、総カバレッジ率を確認できません。

1
ゲーム業界では、ゲーム/レンダリングの視覚的な部分に自動テストを使用していますか?どうやって?
ゲームの一部は、自動化された方法(ロジック、数学、入力処理)で簡単にテストできます。しかし、純粋に視覚的で簡単にテストできないものもたくさんあります。 ゲーム業界がこれをすべて手動テストに任せたとしたら、私は驚きます。十分なお金があるので、少なくともゲームの視覚的な側面のいくつかを回帰テストできるように努力が払われたと思います。 これは本当ですか?もしそうなら、ゲームのレンダリングをテストすることができる可能な方法は何ですか?出力のキャプチャと画像の比較(これは信頼できますか?)?低レベルでグラフィックカードからのデータをインターセプトしますか?その途中で頂点情報(など)をキャプチャするグラフィックスカード?可能性はたくさんあるようです。しかし、これに関する情報は見つかりません:( 注:この質問はこの質問の重複であるとマークされていましたが、これを行う方法について特定のtech / frameworks / toolsについては質問していませんが、このプラクティスに関するアイデア、および実際のゲーム業界が行っていること(ある場合)彼らはまったくそうします)。

2
副作用の多いコードの単体テスト
ロボットを実行するためのC ++コードを書き始めていますが、実際にできる場合は、単体テストを組み込む方法がわかりません。私は、自動的にスケジュールされて実行されるロボットの「コマンド」の作成を可能にするライブラリーを提供されています。これらのコマンドを作成するためのメカニズムは、それらが提供するコマンドの基本クラスをサブクラス化し、仮想実装することでvoid Initialize()、void Execute()、およびvoid End()方法を。これらの機能は、ロボットに対して何かを行う(モーターの実行、ピストンの伸長など)副作用のためにのみ実行されます。このため、ライブラリ全体をモックしてロボットの状態の前後を確認できるようにするまでは、ユニットテストをコードに添付する場所は実際にはありません。過度に負担にならない、これを単体テストする方法はありますか? 編集する ライブラリの機能について誤解を招いていたと思います。ライブラリは、ロボットへのインターフェースのほとんどとコマンド/スケジューリングシステムを提供するため、コマンドの基本クラスをモックするほど単純ではないため、ハードウェアへのインターフェース全体をモックする必要があります。残念ながら、そのための時間はありません。

1
どれだけあざけることが「ちょうどいい」ですか?
「依存する」と確信しているので、冗談めかして質問にタイトルを付けましたが、特定の質問があります。 多くの依存関係の深い層を持つソフトウェアで作業している私のチームは、モックをかなり広範囲に使用して、各コードモジュールをその下の依存関係から分離することに慣れています。 したがって、このビデオでロイ・オセロベが5%程度の時間だけモックを使用すべきであると示唆していることに驚きました。私たちは70-90%のどこかに座っていると思います。他の同様のガイダンスも時々見ました。 私は「統合テスト」の2つのカテゴリーと見なすものを定義する必要があります。これらは非常に異なるため、実際には異なる名前を付ける必要があります。1)複数のコードモジュールを統合するインプロセステストと2)話し合うアウトプロセステストデータベース、ファイルシステム、Webサービスなどに対応しています。私が関心を持っているのはタイプ1で、複数のコードモジュールをすべてインプロセスで統合するテストです。 私が読んだコミュニティガイダンスの多くは、単体テストは正確な場所に関する正確なフィードバックを提供するため、多数の分離された細粒度の単体テストと少数の粗粒度のエンドツーエンド統合テストを優先する必要があることを示唆しています回帰が作成された可能性がありますが、セットアップが面倒な大まかなテストは、実際にはシステムのエンドツーエンドの機能をより多く検証します。 このため、これらの個別のコード単位を分離するには、モッキングをかなり頻繁に使用する必要があるようです。 次のようなオブジェクトモデルがあるとします。 ...また、アプリケーションの依存関係の深さは、この画像に収められるよりもはるかに深くなるため、2〜4層と5〜13層の間に複数の層Nがあることを考慮してください。 ユニット#1で行われている簡単な論理決定をテストする場合、およびすべての依存関係がそれに依存するコードモジュールにコンストラクター注入されている場合、たとえば、2、3、および4は、モジュール1にコンストラクター注入されます。画像では、2、3、および4のモックを1に注入するほうがはるかに便利です。 それ以外の場合は、2、3、および4の具象インスタンスを作成する必要があります。これは、追加のタイピングだけでは難しい場合があります。多くの場合、2、3、および4は、コンストラクター要件を満たし、グラフに従って(およびプロジェクトの現実に従って)、困難な場合があります。Nから13の具体的なインスタンスを構築して、 2、3、4。 この状況は、2、3、または4が特定の方法で動作して、#1の単純な論理決定をテストできるようにする必要がある場合、より困難になります。2、3、または4が必要な動作をするようにするには、オブジェクトグラフ/ツリー全体を一度に理解し、「精神的に推論する」必要があるかもしれません。多くの場合、myMockOfModule2.Setup(x => x.GoLeftOrRight())。Returns(new Right());を実行する方がはるかに簡単です。モジュール2が正しく進むように指示したときに、モジュール1が期待どおりに応答することをテストします。 2 ... N ... 13の具象インスタンスをすべて一緒にテストすると、テスト設定は非常に大きくなり、ほとんどが重複します。テストの失敗は、リグレッションの失敗の場所を正確に特定するのに非常に適しているとは限りません。テストは独立していません(別のサポートリンク)。 当然のことながら、これらのモジュールがそれ以上依存することはほとんどないため、最下層の相互作用ベースのテストではなく、状態ベースのテストを行うことは、しばしば妥当です。しかし、モジュールを一番下より上に分離するために、モッキングが定義上ほとんど必要であるようです。 このすべてを踏まえて、私が欠けているかもしれないものを誰かに教えてもらえますか?私たちのチームはモックを使いすぎていませんか?あるいは、ほとんどのアプリケーションの依存関係の層が十分に浅く、統合されたすべてのコードモジュールをテストすることが実際に合理的である(私たちのケースを「特別な」ものにする)と、通常の単体テストガイダンスに何らかの仮定があるのでしょうか。あるいは、おそらく別の方法として、私たちのチームは私たちの制限されたコンテキストを適切に制限していませんか?

4
単体テストで、なぜリポジトリを2回作成するのですか?
先日、ユニットテストについて少し読んでいて、人々がリポジトリインターフェイス(つまりIExampleRepository)を作成してから、実際のリポジトリ(public class ExampleRepository : IExampleRepository)とユニットテストに使用するリポジトリ()を作成する例をいくつか見ましたFakeExampleRepository : IExampleRepository。 IExampleRepositoryそれらはと同じ方法を実施したExampleRepositoryが、異なるLINQクエリと、。 ここの目的は何ですか?コードの単体テストの一部は、メソッドが正しく機能することを確認することだと思いましたか?しかし、「実際の」クエリとテスト内のクエリの2つのまったく異なるクエリを使用すると、テストはどの程度意味がありますか?

3
大きなメソッドをリファクタリングして何も壊さないようにする場合、何が役立ちますか?
私は現在、大規模なコードベースの一部をリファクタリングしており、ユニットテストはまったくありません。私は力ずくでコードをリファクタリングしようとしました。つまり、コードが何をしていてどのような変更が意味を変えないかを推測しようとしましたが、成功しませんでした。コードベースのすべての機能をランダムに破壊しました。 リファクタリングには、レガシーC#コードをより機能的なスタイルに移行すること(レガシーコードはLINQを含む.NET Framework 3以降の機能を使用しません)、コードのメリットがあるジェネリックの追加などが含まれることに注意してください。 費用がいくらかかかるので、正式な方法は使用できません。 一方、少なくとも「リファクタリングされたレガシーコードにはユニットテストが付属する」というルールは、いくらコストがかかっても、厳密に従うべきだと思います。問題は、500 LOCプライベートメソッドのごく一部をリファクタリングするときに、単体テストを追加することが難しいように見えることです。 特定のコードに関連する単体テストを知るのに役立つものは何ですか?コードの静的分析が何らかの形で役立つと思いますが、次の目的で使用できるツールと手法は何ですか。 どのユニットテストを作成すればよいかを正確に把握し、 そして/または私が行った変更が元のコードに影響を及ぼし、今とは異なる方法で実行されているかどうかを知っていますか?

2
動的言語でモックを作成しているときにタイプエラーはどのように検出されますか?
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) // …

5
戦略パターンにリファクタリングされた関数を単体テストする方法は?
私のコードに次のような関数がある場合: 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クラスもテストする必要がありますか?

3
「早期リリースが頻繁にリリースされる」環境での単体テストの関連性は何ですか?
過去1年ほどの間、私はチームをリリース-アーリー-リリース-頻繁な開発モード(別名:アジャイルではなく迅速なアプリケーション開発)に向けました。ビルドを閉じる方法の詳細については、こちらの回答を参照してください 。RAD環境でのリリース品質を向上させる簡単な方法 私たちがRADを採用したとき、人々は非常に独立していて、最初にユニットテストを行っていました。統合テストはプロセスのかなり後の方で行われました。それは、正式な強制をあまり行わなかった彼らにとって自然なプロセスでした。今の状況はかなり異なります: プラットフォーム全体は、ホットスポットがなく、クライアント側で機能する確立されたビルド/リリースとうまく統合されています。 新しい機能の要件は今後も続き、必要に応じて段階的に構築していきます。 独立した開発グループがプロセスを正しくフォローしている一方で、複雑で自明ではない状況が原因で重大な障害が発生しているため、システムの全体的なダイナミクスは非常に重要です。 システムの多くの部分には新しいアルゴリズムと研究入力が含まれるため、明確に定義されたソフトウェアでの機能テストのように、課題(およびテストのメカニズム)が常に正しく予測されるとは限りません。 最近、プロセスの改善が必要かどうかを確認するために、全体像をよりよく把握することを試みていました。チームと一緒に座ったとき、彼らの多くは「私たちはもうユニットテストをしません!」他の人たちは、効果がなくなるので今すぐ始めるべきではないと考えました。 単体テストは比較的成熟したシステムで役立ちますか?ユニットの成熟度に応じて、少なくともテストスコープの重量を量る必要がありますか?単体テストは開発のペースを遅くしますか?単体テストを別の方法で評価する必要はありますか? リリース早期リリースの環境で成熟したプラットフォームをテストするためのベストプラクティスは何ですか?
10 unit-testing  rad 

3
テストデータが必要ですか、それとも単体テストと手動テストに依存できますか?
現在、中規模/大規模のPHP / MySQLプロジェクトに取り組んでいます。私たちはPHPUnitとQUnitでユニットテストを行っており、アプリケーションを手動でテストしている2人のフルタイムテスターがいます。テスト(モック)データは現在、SQLスクリプトで作成されています。 テストデータ用のスクリプトの管理に問題があります。ビジネスロジックはかなり複雑で、テストデータの1つの「単純な」変更によって、アプリケーションにいくつかのバグが発生することがよくあります(実際のバグではなく、無効なデータの産物です)。テーブルの作成と変更は常に行われているため、これはチーム全体にとって大きな負担になっています。 UIを使用して約5分ですべてをアプリケーションに手動で追加できるため、スクリプトでテストデータを維持する意味は本当にわかりません。私たちのPMはこれに同意せず、テストデータで展開できないプロジェクトがあることは悪い習慣だと言います。 テストデータを含むスクリプトのメンテナンスを中止し、テスターがデータなしでアプリケーションをテストできるようにする必要がありますか?ベストプラクティスは何ですか?

3
サプライヤーのWebサービスを呼び出す単体テスト方法
1つのパブリックメソッドSend()といくつかのプライベートメソッドを持つクラスがあります。いくつかのWebサービスを呼び出し、応答を処理します。処理はプライベートメソッドで行われます。 コードを単体テストしたい。私の理解では、単体テストではコードを分離してテストする必要があります(つまり、サプライヤーの応答をモックアップします)。 また、プライベートメソッドを単体テストする必要はないと考えていますが、Send()メソッドをテストするだけでは、コードは分離してテストされておらず、サプライヤの反応に依存しています。 その後、モック応答でテストできるように、プライベートメソッドを公開する必要がありますか?私はクラスだけがそれらを呼び出す必要があるので、それは悪い習慣のようです。 基本的な質問であれば、申し訳ありませんが、単体テストはかなり新しいものです。 私はc#とVS2010を使用しています

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

2
JavaScriptを単体テストするにはどうすればよいですか
私は最近のJavaScriptでの作業に多くの時間を費やしています。私はjavascriptをテストするためにうまくいくように見える方法を見つけていません。私が取り組んだほとんどのWebサイトにはJavaScriptがほとんど含まれていなかったので、これまでは問題になりませんでした。私は今、jQueryを広範囲に使用する新しいWebサイトを持っているので、ほとんどのシステムの単体テストを構築したいと思います。 私の問題はこれです。 ほとんどの関数は、何らかの方法でDOMを変更します。 ほとんどの関数はWebサーバーからのデータも要求し、結果を取得するにはサービスでのセッションが必要です。 ブラウザではなく、コマンドラインまたはテスト実行ハーネスからテストを実行したいと思います。 私が読んでいるはずのヘルプや記事は役に立ちます。

1
ユニットテストジェネレーターは、レガシーコードの操作に役立ちましたか?
テストカバレッジが非常に低い小さな(生成されたものを含めて〜70kLOC)C#(.NET 4.0、一部のSilverlight)コードベースを探しています。コード自体は、ユーザー受け入れテストに合格したという点で機能しますが、脆弱で、一部の領域では十分に分解されていません。通常の容疑者(NMock、NUnit、Silverlightビット用のStatLight)を使用して、レガシーコードの周りに強力な単体テストカバレッジを追加したいと思います。 私の通常のアプローチは、コードの状態に満足するまで、プロジェクト、ユニットテスト、リファクタリングを開始することです。私はこれを何度も行ったことがありますが、うまくいきました。 ただし、今回は、テストジェネレーター(特にPex)を使用してテストフレームワークを作成し、手動で具体化することを考えています。 私の質問は、レガシーコードベースでの作業を開始するときに過去にユニットテストジェネレーターを使用したことがありますか? 私の恐れは、生成されたテストがコードベースの意味のニュアンスを見逃し、コードで意図された動作を明確に表現するテストではなく、カバレッジメトリックのためにテストを行うという恐ろしい状況につながることです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.