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

私のチームのすべてのプログラマーは、単体テストと統合テストに精通しています。私たちは皆それで働いてきました。すべてのテストが書かれています。私たちの中には、自分のコードに対する信頼感が向上したと感じている人もいます。 ただし、何らかの理由で、ユニット/統合テストを作成することは、チームのどのメンバーにとっても反射になりませんでした。実際のコードと同時にユニットテストを書いていないとき、私たちの誰も実際に気分が悪いことはありません。その結果、私たちのコードベースはユニットテストによってほとんど発見されず、プロジェクトはテストされずに本番に入ります。 それに伴う問題は、もちろん、プロジェクトが本番環境にあり、すでに正常に動作している場合、ユニット/統合テストを追加するための時間や予算を獲得することは事実上不可能であることです。 私のチームのメンバーと私はすでにユニットテスト（の値に精通している1、2）それは私たちの自然なワークフローにユニットテストをもたらす助けていないようです。私の経験では、単体テストやターゲットカバレッジを必須にすると、テストの品質が低下し、チームメンバーの速度が低下します。これは、これらのテストを作成するための自己生成の動機がないためです。また、圧力が緩和されるとすぐに、単体テストは記述されなくなります。 私の質問は次のとおりです。チーム内でダイナミック/モメンタムを構築し、自然にそれらのテストを作成および維持したい人を導くのに役立つ実験方法はありますか？

27 project-management  unit-testing  code-quality  integration-testing 

職場では、かなり複雑なシステムがあります。このシステムを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に置き換えてみませんか？それに対して、職場の誰も満足のいく対応をすることができません。 この問題に関するガイダンスは大歓迎です。

10 unit-testing  testing  qa  acceptance-testing  integration-testing 

HSQLDBは素晴らしいです。また、組み込みモード（専用サーバーは不要）を備えているため、Proof of Conceptsなどの迅速なプロトタイピングが可能になり、さまざまなデータをすばやく簡単に保存できるため、本番環境ですぐに使用できるアプリケーションにも最適です。 ただし、私が過去数年取り組んできたプロジェクトの少なくとも90％は、SQLデータベースを何らかの方法で処理する場合、組み込みHSQLDBを使用するユニットテストを避けられません。 確かに、これらのプロジェクト（ほとんどの場合、標準のMaven構造を使用します）には、大量の「単体テスト」（または少なくとも、ある種のテストがありますが、「単体テスト」領域にあります）があります。いくつかのCRUD操作を実行して結果を確認するために、HSQLDBの1つ以上の埋め込みインスタンスを使用するプロジェクト（「src / test / java」など）の）。 私の質問は、これはアンチパターンですか？HSQLDBは​​簡単に統合でき、組み込みサーバーは非常に軽量であるため、実際のデータベースの「モックアップ」として見過ごされがちですが、そうでない場合はどうでしょうか。（それらのそれぞれは、「何か」で構成されているので、このようなテストは、より統合テストのように扱われるべきではないと、データベース・サーバーとの「何か」の統合という）？または、「単体テスト」定義に何か欠けているのでしょうか。このようにHSQLDBを使用すると、「単体テスト」定義の「依存関係を模擬し、単体のみをテストする」部分に固執すると言えます。

9 database  unit-testing  mocking  integration-testing 

私のチーム内での最近の議論は私を不思議に思いました。基本的なトピックは、機能/統合テストでいくら、何をカバーするかということです（確かに、それらは同じではありませんが、例は重要ではないのでダミーです）。 次のような「コントローラ」クラスがあるとします。 public class SomeController { @Autowired Validator val; @Autowired DataAccess da; @Autowired SomeTransformer tr; @Autowired Calculator calc; public boolean doCheck(Input input) { if (val.validate(input)) { return false; } List<Stuff> stuffs = da.loadStuffs(input); if (stuffs.isEmpty()) { return false; } BusinessStuff businessStuff = tr.transform(stuffs); if (null == businessStuff) { return false; …

8 java  unit-testing  testing  test-automation  integration-testing