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

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 もちろん、エラーメッセージまたは警告にログフレームワークを使用することは非常に有効です。ただし、短時間で新しいことを試してみたい場合は、System.out.println（）を使用することがあります。 System.out.println（）を使って簡単なテストを行うのは本当に悪いのでしょうか？

18 java  programming-practices  testing  code-quality  source-code 

ユニットテストを行っています。 1つの機能をテストしようとしています。 テストコンポーネントから呼び出します。しかし、リモート関数が例外を処理できない場合、テスターコンポーネントも例外を取得します。 テスターコンポーネントで例外が発生することを心配する必要がありますか？ ありがとう。 編集： PS： エラーを投げることは良いことですが、最後の選択肢になるまでエンドユーザーにではなく、他の機能に対してのみです！ OMG私はプログラミングの見積もりを書きました!!

18 testing  unit-testing  exceptions 

製品と一緒にテストコードを出荷したいと思います。具体的には、プログラムのコピーを持っている人がだれでも「セルフテスト」ボタンを押すか、コマンドラインで--self-testに合格してユニットの完全なスイートを実行できるようにするオプションを提供します。統合テスト。 私は主にこれを現場で発見された問題のデバッグに役立てたいと思っています。そのため、バグレポートがエンドユーザーから届くと、「また、これら3つのテストが私のマシンで失敗しました」によってサポートされる可能性があります。手動テスターでユニットを実行できるようにしたい| 統合テストも同様です。 ただし、チームのテストでは、テストコードは製品コードではないため、出荷されません。ほとんどのオープンソースプロジェクトにはテストスイートが同梱されているため、私は実際にはこの議論を受け入れていません。閉じたソフトウェアでは珍しいようです。 議論のどちらの側にも証拠や逸話を支持したいと思います。どのスタック交換サイトが最も適切かを推測しましたが、これが適切でない場合はお知らせください。

17 c++  unit-testing  testing 

ユニット/機能テストなしの大規模なエンタープライズレベルのアプリケーションがあるとします。非常に厳しい締め切りのために、開発中にテスト駆動型の開発プロセスはありませんでした（わからない場合、締め切りを約束するべきではありませんが、何が行われたかはわかりません！） すべての期限が過ぎ、物事が落ち着いたので、誰もが生産的なTDD / BDDベースのチームに私たちを変えることに同意しました。 問題は、すでにあるコードについてです：（1）すべてが完全に正常に動作していても、ほとんどの開発を停止し、最初から可能なテストケース全体を書き始めることはまだ大丈夫ですか？ ？または、（2）何か悪いことが起こるのを待ってから、修正中に新しい単体テストを作成するか、（3）以前のコードを忘れて、新しいコードのみの単体テストを作成し、次の主要なリファクタリングにすべてを延期する方がよいでしょう。 このようないくつかの良い関連記事があります。私たちには非常に限られた時間しかなく、他の多くのプロジェクト/作品が私たちを待っているので、これに投資する価値があるかどうかはまだわかりません。 注：この質問は、開発チームの完全に厄介な状況を説明/想像しています。これは私や同僚のことではありません。それは単なる想像上の状況です。これは絶対に起こらないか、開発マネージャーがそのような混乱に責任があると思うかもしれません！しかし、とにかく、行われたことが行われます。可能であれば、これは絶対に起こらないと思われるからといって、投票しないでください。

17 unit-testing  testing  tdd  bdd  acceptance-testing 

過去には、さまざまな環境で働いてきました。デスクトップアプリ、ゲーム、埋め込みコンテンツ、Webサービス、コマンドラインジョブ、Webサイト、データベースレポートなど。これらの環境はすべて同じ特徴を共有しました。複雑さやサイズに関係なく、テストするマシンまたは開発環境でアプリケーションのサブセットまたはスライスを常に保持できました。 今日はしません。今日私は、スケーラビリティに主眼を置いている環境にいることに気づきました。環境を再現することは法外に費用がかかります。環境の一部を取りますが、もっともらしい（一部のピースはシミュレートする必要があるか、実行しないようにシングルインスタンスモードで使用する必要があります）が、同時実行性とロードを不明瞭にするため、目的を無効にします実際のシステムが遭遇します。小さな「テスト」システムにも欠陥があります。2つのノードがある場合と64のノードがある場合は、動作が異なります。 最適化への私の通常のアプローチ（測定、何かを試す、正しさを検証する、違いを測定する、繰り返す）は、重要な問題の部分（同時実行性の堅牢性とパフォーマンスの下で効果的にステップ2と3を実行できないため、ここでは実際に機能しません負荷）。ただし、このシナリオはユニークではないようです。この種の環境でこの種のタスクを行うための一般的なアプローチは何ですか？ 関連する質問がいくつかあります。 この質問は、ハードウェア（スペクトルアナライザーなど）が利用できないことに関するものであり、（比較的）簡単にエミュレートできます。 この質問は、実稼働環境にのみ存在するバグを追跡することに関するものです。これは役に立ちますが、異なる種類のアクティビティです。

17 testing  optimization  scalability 

JDBCアクセスにSpringを使用するDAOメソッドがあります。これは、アイテムを販売する売り手の成功率を計算します。 コードは次のとおりです。 public BigDecimal getSellingSuccessRate(long seller_id) { String sql = "SELECT SUM(IF(sold_price IS NOT NULL, 1, 0))/SUM(1) FROM transaction WHERE seller_id = ?"; Object[] args = {seller_id}; return getJdbcTemplate().queryForObject(sql, args, BigDecimal.class); } このメソッドまたはDAOメソッドをJUnitでテストするにはどうすればよいですか？データアクセスロジックをテストするためのベストプラクティスは何ですか？いくつかのデータがロードされた埋め込み可能なデータベースに対してテストすることを考えていますが、RDBMSとスキーマの点で本番環境と同様の統合テストを行うべきではありませんか？

17 java  programming-practices  testing  tdd 

特に、私は次の側面に興味があります。 テストケースが間違っている（または古くなっている）ため、修復（または破棄）する必要があることをどのようにして知るのですか？つまり、テストケースが無効になった場合でも、テストケースが合格し、サイレントのままになる可能性があります。これにより、ソフトウェアが正常に動作していると誤って信じることができます。それでは、テストスイートのこのような問題をどのように実現しますか？ テストスイートがもはや十分ではなく、新しいテストケースを追加する必要があることをどのように知っていますか？これは要件の変更と関係があると思いますが、テストスイートの妥当性をチェックするための体系的なアプローチはありますか？

17 testing  maintenance 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 たまたまシステム管理者を知っていましたが、彼によると、テスト担当者は開発者と比較して組織の好みを与えられていません。ソフトウェアのリリースはテスターなしでは不可能であることは間違いありませんが、私はテストに手を出したことがないのであまり気づいていません。意図的な違反はありません。

17 testing 

プログラマーは、テストを設計する際にテスターをどれだけ助けるべきですか？ 私は彼らがまったく助けになるとは思わない。私の心配は、彼らがテスターが彼ら自身のコードのためのテストを設計するのを助けるならば、彼らが彼らの自身の偏見とそのコードに関する盲点でテスターに​​「感染」するだろうということです。 テスターがテストを作成するために必要な情報を提供するには、要件が十分でなければならないと感じています。プログラマーが気になる実装の一部がある場合、ユニットテストを実装してその部分をテストするか、独自の非公式のシステムテストを実行してその部分をテストすることは彼らの義務だと思います。 しかし、私が知っている誰もがこれに同意しているわけではありません（そして、ある程度彼らのポイントを理解しています）。他の人はこれについてどう思いますか？これはどこでも文献で議論されていますか？

17 team  testing 

どちらかを持っている方が良いですか 同じテストが成功する確定的なテストスイート 非決定的テストスイート。これは、より多くのケースをカバーする可能性があります。 ？ 例： テストスイートを作成して、MVCアプリケーションのコントローラー機能をテストします。コントローラーは、テスト中の入力としてデータベースからのアプリケーションデータを必要とします。これを行うには2つのオプションがあります。 テストデータベースのどの行を入力として選択するかをハードコーディングします（10行目と412行目など） 乱数ジェネレーターを使用して、データベースからデータを擬似ランダムに選択します（乱数ジェネレーターによって選択された2行） 1つ目は決定論的です。同じリビジョンのコードに対してテストを実行するたびに、同じ結果が得られます。2番目は非決定的です。テストスイートを実行するたびに、異なる結果が得られる可能性があります。ただし、ランダムに選択されたデータは、データエッジケースのより適切な表現である可能性があります。予測不可能なデータをコントローラーに送るユーザーをよりよくシミュレートするかもしれません。 どちらか一方を選択する理由は何ですか？

17 testing  mvc 

これらは、TDDに関するRobert C. Martinの規則です。 失敗した単体テストに合格しない限り、実稼働コードを作成することはできません。 失敗するのに十分な数以上の単体テストを作成することはできません。コンパイルの失敗は失敗です。 1つの単体テストに合格するのに十分な量を超える量産コードを記述することはできません。 価値があると思われるが、本番コードを変更せずに合格するテストを作成する場合： それは何か間違ったことをしたということですか？ 役立つ場合は、将来そのようなテストを書くことを避けるべきですか？ そのテストをそこに残すか、削除する必要がありますか？ 注： 私はここでこの質問をしようとしていました：ユニットテストに合格することから始められますか？ しかし、私は今まで十分に質問を明確にすることができませんでした。

17 testing  unit-testing  tdd 

唯一の実際のロジックは、外部APIのクエリ構文にあります。APIを照会するかどうかをテストするのではなく、正しいデータが返されるような方法で照会することをテストする必要があります。たとえば、いくつかの擬似コード： function retrieve_related_data(id) { query = "[potentially long, syntactically complex query that uses param id to get some data]"; results = api_wrapper.query(query); return results; } 構成されたAPIを使用したより具体的な例： function retrieveLifeSupportingObjectsWithinRegion(id) { query = " within region(" + id + ") as r find objects matching hydration>0 and temp_range has 75 send name, …

16 unit-testing  testing  integration-tests 

ユニットテストは初めてで、DBを呼び出してDTOを設定するREST Webメソッドが1つあります。擬似コードは public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } 私の疑問は、含まれるこれらのメソッドとテストのタイプ（Integration / Unit）のテストの書き方です。単体テストの場合、DBにアクセスする必要がありますか。そうであり、顧客IDを渡してアサーションをほとんど行わない場合、データが最終的に変更されて失敗する可能性があります。 ここでこれらの概念を理解している何かが欠けていると思います。

16 testing  unit-testing  rest  integration-tests 

私は、スクラム方式を使用したソフトウェア開発会社において、継続的インテグレーションワークフローがどのように適合するかをよりよく理解するためのアプローチを研究しています。 私はこのようなことを考えています： それは素晴らしいワークフローでしょうか？

16 testing  development-process  scrum  continuous-integration  workflows 

簡単なアプリケーションを顧客の1人に提供するために、小さなサイドプロジェクトを行うように依頼されました。通常、テストニーズをすべて把握しているバックエンドコードで作業しますが、GUIのテストを作成することについてまだ疑わしい喜びがありません。 EXEのテストコードとツール。 私の最初の本能は、テストをアプリケーションコードに単純に含めることでしたが、テスト固有の多数の依存関係を提供する必要があり、特に顧客に出荷しないように指示されました。また、専用のテストツール用に現金を絞り込めないため、手元にあるツール（StoryQ、RhinoMocks、およびNUnitを使用する必要があります。）、これは実際に単純なGUIアプリの動作をテストするのに十分なはずです。したがって、私が見る限り、これにより、デザインを本当にシンプルに保つか、テストのために意図的にオーバーエンジニアリングするかのバランスをとろうとしています。別のライブラリでビジネスロジックを使用してアプリを構築し、通常どおりにライブラリに対してテストするか、アプリケーション設計ではない追加のモジュールを壊さずに実行可能ファイルを許可する他のメカニズムを見つけているようです本当に必要。 編集： この質問は、DLLとは対照的に、NUnitと実行可能ファイルの関係を構築する方法に関するものであり、プレゼンテーションとビジネスロジックを分離する方法に関するものではないことに注意してください。 /編集 だから私の質問は： 単純なGUIアプリケーションを単体テストで構成して、手元にあるツールを使用して、過剰なエンジニアリングに頼らずに状態と動作を適切にチェックできるようにする特定の/推奨の方法はありますか？ （DLLではなく）EXEをテストするときにNUnitを起動/構成する方法に関する基本的なことを見逃していませんか？ このすべてをどのように達成するかの例の方向性を提供または指示できますか？ これを行うには複数の方法があるかもしれないことを理解しているので、あなたの経験に基づいて特定の実装ガイドラインを探しています。

16 c#  testing  gui  nunit