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

現在の製品で増加している統合テストの規模を拡大するための技術と戦略を調査しており、開発およびCIプロセスの一部として（人間的に）残ることができます。 約200以上の統合テストで、（デスクトップ開発マシン上で）完全なテスト実行を完了するために1時間のマークをすでに打っています。これは、定期的なプッシュプロセスの一部としてスイート全体を実行することを許容する開発者の能力に悪影響を及ぼしています。それは、それらをうまく作成することについて規律付けられる動機に影響しています。主要なシナリオのみを前面から背面まで統合テストし、テストを実行するたびにゼロから構築される本番環境をミラーリングする環境を使用します。 実行に時間がかかるため、テスト実行の集中度に関係なく、ひどいフィードバックループが発生し、テスト実行の終了をマシンで待機する多くの無駄なサイクルが発生します。フローと進捗、健全性、持続可能性に対するより高価な悪影響を決して気にしないでください。 この製品の速度が低下し始める前に、10倍以上の統合テストが行​​われると予想されます（実際にはわかりませんが、機能に関してはまだ始まったばかりではありません）。私たちは、数百または数千の統合テストに合理的に期待する必要があります。 明確に言うと、これがユニットテストと統合テストの議論にならないようにしようとすることです。この製品では、TDDを使用した単体テストと統合テストの両方を行っています。実際、アーキテクチャのパターンを他の領域に変更する際に重大な変更を導入する場所を検証する必要があるため、私たちが理にかなっているサービスアーキテクチャのさまざまな層で統合テストを行いますシステム。 技術スタックについて少し。現在、テストをエンドツーエンドで実行するために、（CPUとメモリを集中的に使用する）エミュレーション環境でテストしています。これは、noSqlバックエンド（ATS）の前にあるAzure REST Webサービスで構成されています。Azureデスクトップエミュレーター+ IISExpressで実行することにより、運用環境をシミュレートしています。開発マシンごとに1つのエミュレータと1つのローカルバックエンドリポジトリに制限されています。 また、同じエミュレート環境で同じテストを実行するクラウドベースのCIもあり、現在のCIプロバイダーではクラウドでのテスト実行に2倍の時間がかかります（2時間以上）。ハードウェアパフォーマンスの観点からクラウドCIプロバイダーSLAの制限に達し、テスト実行時の許容値を超えました。公平を期すために、仕様は悪くはありませんが、社内の汚いデスクトップマシンの半分の品質であることは明らかです。 テストの論理グループごとにデータストアを再構築し、テストデータをプリロードするテスト戦略を使用しています。データの整合性を包括的に保証しながら、これにより各テストに5〜15％の影響が追加されます。したがって、製品開発のこの時点では、そのテスト戦略を最適化することはほとんど得られないと考えています。 長いことと短いことです。各テストのスループットを最適化できましたが（それぞれ30％〜50％であっても）、数百のテストで近い将来に効果的にスケーリングすることはありません。1時間は今でも人間の許容範囲をはるかに超えています。それを維持するには、全体のプロセスを1桁改善する必要があります。 そのため、テスト時間を大幅に短縮するために使用できる手法と戦略を調査しています。 より少ないテストを書くことはオプションではありません。このスレッドで議論しないでください。 非常に高価ですが、より高速なハードウェアを使用することは間違いなくオプションです。 並列の別個のハードウェアでテスト/シナリオのグループを実行することも、間違いなく推奨されるオプションです。 開発中の機能とシナリオに関するテストのグループ化を作成することはもっともらしいですが、最終的には、システムが変更の影響を受けないという完全なカバレッジまたは信頼性を証明することはできません。 デスクトップエミュレーターで実行する代わりに、クラウドスケールのステージング環境で実行することは技術的に可能ですが、テスト実行に展開時間を追加し始めます（テスト実行の開始時に、〜20分ごとに展開します）。 システムのコンポーネントを独立した対数部分に分割することはある程度妥当ですが、コンポーネント間の相互作用は時間とともに増加することが予想されるため、その上で限られた燃費が期待されます。（つまり、変更は他の人に予期しない形で影響を与える可能性が高い-システムがインクリメンタルに開発されるときによく起こるように） この分野で他の人がどの戦略（およびツール）を使用しているかを知りたかった。 （他の人が特定の技術セットを使用してこの種の困難に直面している可能性があると信じる必要があります。） [更新：2016年12月16日：結果の議論のため、CI並列テストにより多くの投資をすることになりました：http : //www.mindkin.co.nz/blog/2015/12/16/16-jobs]

21 testing  continuous-integration  integration 

私は、チームで実装しているユニットテストに関して、ますます厄介な問題に取り組んでいます。うまく設計されていないユニットコードをレガシーコードに追加しようとしていますが、実際にテストを追加するのに苦労することはありませんが、テストの結果に苦労し始めています。 問題の例として、実行の一部として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 

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

21 books  testing  unit-testing 

テスターに​​サインオフ権限を与えることは理にかなっていますか？テストチームが 機能、問題などをテストし、合格/不合格ベースで報告するだけで、それらの結果に基づいて行動することができます。 それらの結果に基づいて、リリース自体を保持する権限がありますか？ つまり、テスターは実際にリリースを承認する必要がありますか？私が取り組んでいるテストチームは、彼らがそうしていると感じており、「スコープクリープのテスト」が原因でこれに問題があります。

20 testing  release-management  process 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 自白します。形式化された自動化されたテストは、私のプログラミングの背景の一部ではありませんでした。現在、私は多くの開発者（大部分は何らかの種類のWeb開発者）を抱える非常に大きな会社で働いていますが、彼らのほとんどもテストしていないことは明らかです*。（* 正式に発言し続けるつもりはありません。推測してください。） テストを開始するために組織のサポートを受けるのを待つ場合、それは決して起こりません。経営陣のテストを押して「内部から物事を変えよう」とすると、変化が起こる前に枯渇してしまいます。今すぐテストを開始する必要があります。 しかし、TDDとその同類を使用すると、実動コードと一緒に多くのテストコードを作成することになります。バージョン管理システム（すべて集中管理）は、テストコードを保存するために編成されていません。ワークステーション上ですべての場所を見つける必要があります。 価値のない、またはツールを提供しない文化の中で、ソフトウェアテストの個人的な実践を始めることは可能ですか？公式のツールと組織にテスト、フレームワーク、および自動化の場所がない場合にテストできるようにするために、どのようなテクニックとツールを使用しますか？

20 testing  tdd 

既知のバグを含む製品をいつ出荷できますか？

20 testing  quality 

組織のガイドラインをまとめるための単体テストのベストプラクティスを調査する際、テストフィクスチャ（テストクラス）を分離するか、1つのクラスのすべてのテストを1つのファイルに保持する方が良いか便利かという問題に直面しました。 ちなみに、純粋な意味での「ユニットテスト」とは、単一のクラス、テストごとに1つのアサーション、モックされたすべての依存関係などを対象とするホワイトボックステストのことです。 シナリオの例は、CheckInとCheckOutという2つのメソッドを持つクラス（Documentと呼ばれる）です。各メソッドは、動作を制御するさまざまなルールなどを実装します。テストごとに1つのアサーションルールに従って、メソッドごとに複数のテストがあります。およびのDocumentTestsような名前を持つ単一のクラスにすべてのテストを配置できます。CheckInShouldThrowExceptionWhenUserIsUnauthorizedCheckOutShouldThrowExceptionWhenUserIsUnauthorized または、2つの個別のテストクラスを持つことができます：CheckInShouldとCheckOutShould。この場合、テスト名は短縮されますが、特定の動作（メソッド）のすべてのテストが一緒になるように整理されます。 私はどちらのアプローチにも賛否両論があると確信しており、誰かが複数のファイルでルートを行っているのかどうか疑問に思っています。または、単一ファイルのアプローチを選択した場合、なぜそれが良いと感じるのですか？

20 testing  tdd  unit-testing 

私は大規模な組織をサポートする小さなプログラミングチームで働いています。今年、マネージャーは、Oracle Apexテクノロジーを使用して会社データの大部分を処理することを決定しました。 Apexサーバーが1つしかないことを除いて、これは問題ありません。マネージャーは、すべてがその1つのインスタンスで発生することを決定しました。私たちのチームはアプリを開発していますが、マネージャーはそれらをデモし、社内のクライアントはそれらを使用します。 Apexへの投資が増え、アプリがより複雑になり、ユーザーの数が増えるにつれて、これが悪化すると予想されます。ベストプラクティスは、開発環境、テスト環境、および運用環境を別々にすることだと聞きましたが、なぜそうなのですか？ 質問：開発環境、テスト環境、および運用環境を個別に用意する必要があるのはなぜですか？

19 testing  development-environment  quality  production  environment 

私はパーサーを書いており、その一部として、Expander単一の複雑なステートメントを複数の単純なステートメントに「拡張」するクラスがあります。たとえば、これはこれを展開します： x = 2 + 3 * a に： tmp1 = 3 * a x = 2 + tmp1 今、私はこのクラスをテストする方法、具体的にはテストを配置する方法を考えています。入力構文ツリーを手動で作成できます。 var input = new AssignStatement( new Variable("x"), new BinaryExpression( new Constant(2), BinaryOperator.Plus, new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a")))); または、文字列として記述して解析することもできます。 var input = new Parser().ParseStatement("x = 2 + 3 * a"); …

19 unit-testing  testing  integration-tests 

私は本当に単体テストとTDDに夢中になりました-私はテストに感染しています。 ただし、ユニットテストは通常​​、パブリックメソッドに使用されます。ただし、プライベートメソッドでもいくつかの仮定（アサーション）をテストする必要がある場合があります。これは、それらの一部が "危険"であり、リファクタリングがそれ以上役に立たないためです。（フレームワークをテストすることでプライベートメソッドをテストできることはわかっています）。 したがって、プライベートメソッドの最初の行と最後の行の両方がアサーションであることが私の習慣になりました。 ただし、パブリックメソッド（およびプライベートメソッド）でアサーションを使用する傾向があることに注意してください。パブリックメソッドの前提条件は、ユニットテストフレームワークによって外部からテストされるため、これは「テストの重複」でしょうか。 誰かがあまりにも多くのアサーションをコードの匂いだと考えることはできますか？

19 testing  code-quality  tdd  code-smell  assertions 

一緒に仕事をしている優秀な開発者が、私たちが継承したコードに機能を実装するのに苦労したことを最近教えてくれました。彼は、問題はコードを追跡するのが難しいということだと言いました。そのことから、私は製品をより深く見て、コードパスを確認することがどれほど難しいかを理解しました。 非常に多くのインターフェースと抽象レイヤーを使用していたため、物事の始まりと終わりを理解しようとするのは非常に困難でした。私は過去のプロジェクト（きれいなコードの原則に気付く前に）を見ていた時間について考えさせられ、主にコードナビゲーションツールが常にインターフェイスに到達するため、プロジェクトを回避することは非常に困難であることがわかりました。具体的な実装や、プラグインタイプのアーキテクチャで何かが接続されている場所を見つけるには、さらに多くの労力が必要です。 この理由から、一部の開発者は依存性注入コンテナを厳密に拒否しています。ソフトウェアのパスを非常に混乱させるため、コードナビゲーションの難易度は指数関数的に増加します。 私の質問は次のとおりです。フレームワークまたはパターンがこのように多くのオーバーヘッドを導入する場合、それは価値がありますか？実装パターンが不十分な場合の症状ですか？ 開発者は、フラストレーションを乗り越えるために、抽象化がプロジェクトにもたらすものの全体像を調べる必要があると思います。しかし、通常、彼らにその全体像を見せることは困難です。IOCとDIのニーズをTDDで販売できなかったことを知っています。これらの開発者にとって、これらのツールを使用すると、コードの可読性が非常に低下します。

19 testing  code-quality  tdd  code-smell  dependency-injection 

テストに関しては、2つのオプションが考えられます。 テストとアプリケーションの両方を1つのイメージに入れます。 イメージにはアプリケーションコードのみを含めます。メインイメージの後にビルドし、いくつかのレイヤーを追加するテスト固有のコンテナーを作成します（テストコード、依存関係など）。 最初のオプションでは、コンテナをテストし、テストしたとおりに出荷できます。明らかな欠点は、不要なコード（および潜在的にテストデータ）がイメージに含まれることです。 2番目のオプションでは、出荷されるイメージはテストされるイメージとまったく同じではありません。 どちらも悪い戦略のように見えます。3番目のより良い戦略はありますか？

19 unit-testing  testing  docker  test-automation 

「フィクスチャ」の概念を理解するのに多少の困難があります。テストスイートとは何か、テストケース、テスト実行は知っていますが、「フィクスチャ」とは正確には何ですか？パラメーター化されたテストケースですか？ 「フィクスチャ」という用語の意味またはセマンティクスは、プログラミング言語またはテストフレームワークによってわずかに異なる可能性があるように思えますか？私はphpunitフィクスチャだと思う 「ワールドを既知の状態に設定し、テストが完了したときに元の状態に戻すコード。この既知の状態は、テストのフィクスチャと呼ばれます。」 「フィットネスフィクスチャ」とは少し異なります 「フィクスチャは、Wikiページとテスト対象の実際のシステムであるテスト対象システム（SUT）の間の橋渡し役です。」 この質問に答えることができるソフトウェアテストの専門家がここにいますか？他のプログラミング言語への参照は大歓迎です。

19 java  php  testing  terminology  definition 

アイム統合のみ公開APIを使用して、システムをテストします。次のようなテストがあります。 def testAllTheThings(): email = create_random_email() password = create_random_password() ok = account_signup(email, password) assert ok url = wait_for_confirmation_email() assert url ok = account_verify(url) assert ok token = get_auth_token(email, password) a = do_A(token) assert a b = do_B(token, a) assert b c = do_C(token, b) # ...and so on... 基本的に、単一のトランザクションの「フロー」全体をテストしようとしています。フローの各ステップは、成功する前のステップに依存します。私は自分自身を外部APIに制限しているため、データベースに値を突っ込むだけではいけません。 したがって、 …

18 testing 

統合テストのベストプラクティスから、テストを実行する環境が運用環境（オペレーティングシステムを含む）に可能な限り似ているべきだということも多く聞いたため、テストに使用される多くのインメモリデータベース実装を見ると、本当に混乱しています。 、ライブラリ、データベースエンジンなど ここで何が欠けていますか？

18 testing