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

TDDについて多くのことを読みましたが、まだ疑問があります。たとえば、次のクラス図があります。 これは、TDDとモックオブジェクトについて学ぶための簡単な例です。 どのテストを最初に書くべきですか？製品、次にライン、最後に注文？その場合、ラインと製品を使用して注文をテストする必要がありますか、またはモックオブジェクトを使用する必要がありますか？モックオブジェクトはいつ使用する必要がありますか？XPおよびTDDでUMLを使用する必要がありますか？ 私はまだこれらのものを得ていません。

14 php  unit-testing  tdd  mocking 

単体テストは100％ですか、それともまったく関係ありませんか？ 私は古いプロジェクトを閲覧し、機能の追加を開始しました。今回は単体テストです。ただし、単体テストのない過去のコンポーネントを再利用する場合、これは最終的には価値がありませんか？ 以前のすべてのクラスの単体テストを作成する必要があり、気にする必要はありませんか、または追加する新しいものの単体テストのみを作成しても大丈夫ですか？

14 unit-testing 

クラス/モジュール/パッケージ/などの内部/プライベートコンポーネントをどの程度単体テストしますか？それらをすべてテストしますか、それとも外部とのインターフェースをテストするだけですか？これらの内部の例は、プライベートメソッドです。 例として、1つの中央プロシージャから呼び出されるいくつかの内部プロシージャ（関数/メソッド）を持つ再帰降下パーサーを想像してください。外の世界への唯一のインターフェイスは中央の手順であり、文字列を受け取り、解析された情報を返します。他のプロシージャは文字列のさまざまな部分を解析し、中央プロシージャまたは他のプロシージャから呼び出されます。 当然、外部文字列をサンプル文字列で呼び出し、手で解析した出力と比較して、外部インターフェイスをテストする必要があります。しかし、他の手順はどうですか？それらを個別にテストして、サブストリングが正しく解析されることを確認しますか？ 私はいくつかの議論を考えることができます： 長所： より多くのテストが常に優れており、これはコードカバレッジの向上に役立ちます 一部の内部コンポーネントは、外部インターフェイスに入力を与えることにより、特定の入力（エッジケースなど）を与えるのが難しい場合があります。 より明確なテスト。内部コンポーネントに（修正された）バグがある場合、そのコンポーネントのテストケースは、バグがその特定のコンポーネントにあったことを明確にします 短所： リファクタリングは非常に苦痛で時間がかかります。何かを変更するには、外部インターフェースのユーザーが影響を受けていない場合でも、ユニットテストを書き直す必要があります 一部の言語およびテストフレームワークでは許可されていません あなたの意見は？

14 testing  unit-testing  test-coverage 

私のクラスが所有する列挙型の値を処理するためにswitchステートメントを使用していて、可能な値ごとにケースがある場合-「デフォルト」のケースを処理するコードを追加する価値はありますか？ enum MyEnum { MyFoo, MyBar, MyBat } MyEnum myEnum = GetMyEnum(); switch (myEnum) { case MyFoo: DoFoo(); break; case MyBar: DoBar(); break; case MyBat: DoBat(); break; default: Log("Unexpected value"); throw new ArgumentException() } これは、このコードに到達できない（ユニットテストでも）ことが原因だとは思いません。私の同僚はこれに同意せず、これがMyEnumに追加される新しい値によって引き起こされる予期しない動作から私たちを保護すると考えています。 コミュニティとは何ですか？

14 unit-testing  maintenance  enum 

そのため、ユニットテストはできる限り本で作成しようとしていますが、いくつかの単純な追加/削除メソッドをテストするときは面倒になります。 addメソッドの場合、基本的にダミーオブジェクトを作成して追加する必要があり、テストが成功した後、ダミーオブジェクトを削除する必要があります。 削除テストでは、削除できるようにダミーオブジェクトを作成する必要があるのは明らかです。 1つのテストが失敗した場合にわかるように、他のテストも失敗します。どちらも必要なためです。 「注文をキャンセルする」というテストを書く必要があるシステムでも同じです...最初にキャンセルするにはダミーの注文が必要になりますが、これは単体テストのガイドラインに反しませんか？ このようなケースはどのように処理されるのですか？

14 unit-testing 

Webアプリを作成するときは、ブラウザで作業をテストして、エラーが表示されるかどうかを確認し、修正します。私は複雑なアプリケーションを作成しましたが、この方法でのテストは簡単で高速です。私はyoutubeでphpunitに関する多くのビデオを見ましたが、その目的を見つけることができません。このライブラリが便利なのはなぜですか？cakephpやzendのようなphp framworksにはphpunitがもっとありますか？コアphpだけのフレームワークは使用しません。phpunitは私にとって便利ですか？はいの場合、どのように？ xdebugもありますが、関連するかどうかはわかりません。

14 php  unit-testing  web-applications 

時には、他の開発者が書いたコードの単体テストケースを書くことになります。開発者が何をしようとしているか（ビジネスの部分）が本当にわからない場合があり、テストケースを操作して緑色の線を取得するだけです。これらのことは業界では普通ですか？ 通常の傾向は何ですか？開発者は自分で書いたコードの単体テストケースを書くことになっていますか？

14 unit-testing 

私は画像処理（主にOCR）に取り組んでおり、開発に単体テストをどのように統合すべきか疑問に思っています。 私はすでに、より一般的なタイプのコードに対して単体テストを使用していますが、画像処理コードを処理するとき、その処理方法がわかりません。この種のコードには常に画像データの入出力が必要であり、これを模倣することは明らかではありません。今のところ、主に統合テストを行っていますが、実行には時間がかかります。この種のコードをユニットテストに分割して、より迅速に実行できるようにするためのアイデアが欲しいです。 編集：キャラクターの分析は、複数の回転、スケーリング、および形態学的操作を含む多くのステップを経ることができます。これらの手順は、アルゴリズムの開発中に頻繁に変更されます。したがって、テスト中に入力と期待される出力は大きく変化する可能性があります。各文字は100x100ピクセルにすることができるため、コード内でハードコーディングしたり、生成されたデータを操作したりするのは問題ありません。

14 testing  unit-testing  tdd  integration-tests  mocking 

Strategyパターンは、巨大なif ... elseコンストラクトを回避し、機能の追加または置換を容易にするためにうまく機能します。しかし、それでも私の意見には1つの欠陥が残っています。どの実装でも、分岐構造が必要であるようです。ファクトリまたはデータファイルの可能性があります。例として、注文システムを取り上げます。 工場： // All of these classes implement OrderStrategy switch (orderType) { case NEW_ORDER: return new NewOrder(); case CANCELLATION: return new Cancellation(); case RETURN: return new Return(); } この後のコードは心配する必要はなく、新しい注文タイプを追加する場所は1つだけですが、このセクションのコードはまだ拡張できません。データファイルにそれを引き出すことは、読みやすさをいくらか助けます（議論の余地があります、私は知っています）： <strategies> <order type="NEW_ORDER">com.company.NewOrder</order> <order type="CANCELLATION">com.company.Cancellation</order> <order type="RETURN">com.company.Return</order> </strategies> しかし、これにより、データファイルを処理するための定型コードが追加されます。付与された、より簡単にユニットテスト可能で、比較的安定したコードですが、それでも複雑さが増します。 また、この種のコンストラクトは統合テストがうまくいきません。個々の戦略は今すぐテストする方が簡単かもしれませんが、追加するすべての新しい戦略はテストの複雑さを増すことになります。パターンを使用していなかった場合よりも少ないですが、それはまだあります。 この複雑さを緩和する戦略パターンを実装する方法はありますか？それとも、これはそれと同じくらい簡単で、さらに先へ進んでも、抽象化の別の層を追加するだけで、ほとんどまたはまったく利益がありませんか？

14 design  design-patterns  unit-testing  strategy 

彼の講演TDDでは、それがすべてうまくいかなかったので、Ian CooperはTDDのユニットテストの背後にあるケントベックの当初の意図をプッシュし（特にクラスのメソッドではなく、動作をテストするため）、テストを実装に結合しないように主張しています。 save X to some data source典型的なサービスとリポジトリのセットを備えたシステムのような動作の場合、テストを実装の詳細に結合することなく、特定のメソッドの呼び出しなど、リポジトリを介してサービスレベルで一部のデータの保存を単体テストする方法）？この種のカップリングを避けることは、実際には努力する価値がない/何らかの形で悪いですか？

14 unit-testing  tdd  coupling 

次に例を示します。私のWebアプリケーションには、ドラッグ可能な要素が含まれています。要素をドラッグすると、ブラウザは「ゴーストイメージ」を生成します。ドラッグするときに「ゴーストイメージ」を削除したいので、この動作のテストを作成します。 私の問題は、最初にこのバグを修正する方法がわからないことであり、テストを書く唯一の方法は修正した後です。 などの単純な関数ではlet sum = (a, b) => a - b、コードを記述する前に、なぜsum(1, 2)等しくないかに関するテストを書くことができ3ます。 私が説明しているケースでは、検証が何であるかわからないので、テストできません（アサーションがどうあるべきかわかりません）。 説明されている問題の解決策は次のとおりです。 let dataTransfer = e.dataTransfer let canvas = document.createElement('canvas'); canvas.style.opacity = '0'; canvas.style.position = 'absolute'; canvas.style.top = '-1000px'; dataTransfer.effectAllowed = 'none'; document.body.appendChild(canvas); dataTransfer.setDragImage(canvas, 0, 0); これが解決策だとは知らなかった。ソリューションをオンラインで見つけた後、テストを作成することさえできませんでした。実際に機能するかどうかを知ることができる唯一の方法は、このコードをコードベースに追加し、目的の効果があったかどうかをブラウザで確認することでした テストは、TDDに反するコードの後に​​記述する必要がありました。 この問題に対するTDDアプローチはどうなりますか？コードの前にテストを書くことは必須ですか、それともオプションですか？

13 unit-testing  tdd  language-agnostic 

アプリケーションのバグを修正するために、postLoginという名前の既存のメソッドに呼び出しを追加することにより、という名前のメソッドを変更しましたgetShoppingCart。 コード protected void postLogin() { getShoppingCart(); } ただし、単体テストを作成する最適な方法が何であるかはわかりませんpostLogin。 アプローチ1 Mockitoのverifyを使用して、メソッドが呼び出されたことを確認します。 verify(mock).getShoppingCart(); アプローチ2 ユーザーのショッピングカートの値を取得して、メソッド呼び出しの副作用をテストします。 AssertNotNull(user.getShoppingCart()); 1つのアプローチは他のアプローチよりも優れていますか？

13 java  unit-testing  testing  junit 

値の検証を扱うクラスがたくさんあります。たとえば、RangeValidatorクラスは値が指定された範囲内にあるかどうかをチェックします。 すべてのバリデータクラスには2つのメソッドが含まれます：値is_valid(value)を返すTrueかFalse、値に応じて、ensure_valid(value)指定された値をチェックし、値が有効な場合は何もしないか、値が事前定義されたルールに一致しない場合は特定の例外をスローします。 現在、このメソッドに関連する2つの単体テストがあります。 無効な値を渡し、例外がスローされたことを確認するもの。 def test_outside_range(self): with self.assertRaises(demo.ValidationException): demo.RangeValidator(0, 100).ensure_valid(-5) 有効な値を渡すもの。 def test_in_range(self): demo.RangeValidator(0, 100).ensure_valid(25) 2番目のテストは、例外をスローすると失敗し、ensure_valid何もスローしないと成功しますが、assert内部にs がないという事実は奇妙に見えます。そのようなコードを読んだ人は、何もしていないように見えるテストがなぜあるのかをすぐに自問するでしょう。 これは、値を返さず、副作用のないメソッドをテストするときの現在のプラクティスですか？または、テストを別の方法で書き直す必要がありますか？または、単に私がやっていることを説明するコメントを入れますか？

13 unit-testing  exceptions  readability 

そのため、システム全体で次のコードを使用しています。現在、ユニットテストを過去にさかのぼって記述しています（私の議論ではなかったよりも遅くなっています）が、これがどのようにテスト可能かはわかりませんか？ public function validate($value, Constraint $constraint) { $searchEntity = EmailAlertToSearchAdapter::adapt($value); $queryBuilder = SearcherFactory::getSearchDirector($searchEntity->getKeywords()); $adapter = new SearchEntityToQueryAdapter($queryBuilder, $searchEntity); $query = $adapter->setupBuilder()->build(); $totalCount = $this->advertType->count($query); if ($totalCount >= self::MAXIMUM_MATCHING_ADS) { $this->context->addViolation( $constraint->message ); } } 概念的には、これはどの言語にも適用できるはずですが、私はPHPを使用しています。このコードは、オブジェクトに基づいてElasticSearchクエリオブジェクトを構築するだけで、Searchオブジェクトはオブジェクトから構築されEmailAlertます。これらSearchとEmailAlert'sは単なるPOPOです。 私の問題は、SearcherFactory（静的メソッドを使用する）をモックアウトする方法や、インスタンスSearchEntityToQueryAdapterからの結果を必要とするをモックアウトできないことです。メソッド内の結果から構築されたものを注入するにはどうすればよいですか？たぶん私が知らないいくつかのデザインパターンがありますか？SearcherFactory::getSearchDirector Search 助けてくれてありがとう！

13 design-patterns  php  unit-testing  testing 

典型的なC ++コードは次のとおりです。 foo.hpp #pragma once class Foo { public: void f(); void g(); ... }; foo.cpp #include "foo.hpp" namespace { const int kUpperX = 111; const int kAlternativeX = 222; bool match(int x) { return x < kUpperX || x == kAlternativeX; } } // namespace void Foo::f() { ... …

13 c++  unit-testing