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

私は、社内のいくつかの内部ソフトウェア（Pythonで作成）の2人の開発者のうちの1人です。ソフトウェアは、専用のLinuxボックスで実行するように設計されたサーバーアプリケーションです。現在、SVNリポジトリを保持するボックスが1つあり、このボックスはテストにも使用されます。問題は、Windows上のEclipseを使用してワークステーションで開発しているため、このアプリをWindowsで実行できないことです。 このような環境を適切に整理して、プロジェクトとコードの転送に貴重な時間を無駄にしないようにして、テストできるようにする方法は？ 現在、私はsvnチェックアウトを行っており、いくつかのコードを変更してから、テスト用に開発サーバーにアップロードしています（svn経由ではありません）。サーバー上でテストし、何かを変更し、再度テストします。すべてがコミットされます。この絶え間ないアップロードとテストは、私を夢中にさせます。プロジェクトをサーバー上に保持しようとしました（ホームディレクトリにチェックアウトします）が、これによりEclipseで多くの問題が発生します。 明らかに私はこれについて多くの経験を持っていないので、この種の問題に関するベストプラクティスは何ですか？

12 testing  development-environment 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 今日、私はいくつかのコードの変更をチェックインしましたが、かなり愚かでありながら非常に重要な何かが原因でまったく機能しないことが判明しました。私はそれについて本当に気分が悪く、最終的にそこから何かを学ぶことを望みます。愚かなことは、私はこれらのことを以前にやったことがあり、いつも自分に言い聞かせて、次回はそんなに愚かではないだろうと...そして再び起こり、私はそれについてさらに悪く感じます。 あごを維持し、間違いから学ぶ必要があることは知っていますが、ここにあります。私は自分自身を改善しようとしていますが、これらの出来事を防ぐ方法がわかりません。 だから、今私はあなたにみんなに尋ねています：あなたのコードをテストするときに特定の基本原則がありますか？

12 self-improvement  testing 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 3年前に閉店しました。 私はこれが多少主観的であることを理解していますが、どちらかの良いケースを見つけることができません： 「何かをする必要がある」 「何かする」 推奨スタイルの支持者は、それがあなたが達成しようとしていることを実際に質問することを強制するが、批判者はそれを単に冗長であると感じていると述べている。 これについてコンセンサスがありますか、それとも純粋にスタイルの問題ですか？

12 testing  bdd 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 コンソールアプリ（私のお気に入り）、クイック＆ずさんなフォーム、MSペイント（GUI用）; 標準アプリケーションで最もよく機能するのは何ですか？どうして？

12 development-process  testing 

Effective JavaのItem 18にあるように、スケルトン実装を持っています（詳細な議論はこちら）。これは抽象クラスであり、2つのパブリックメソッドmethodA（）およびmethodB（）を提供し、サブクラスメソッドを呼び出して、抽象化された方法では定義できない「ギャップを埋める」。 最初に具体的なクラスを作成し、そのための単体テストを作成して開発しました。2番目のクラスが来たとき、共通の動作を抽出し、2番目のクラスに「欠落したギャップ」を実装することができました（もちろん、2番目のサブクラスに対して単体テストが作成されました）。 時間が経ち、今では4つのサブクラスがあり、それぞれが具体的な実装に非常に固有の3つの短いプロテクトメソッドを実装していますが、骨格実装はすべての一般的な作業を行います。 私の問題は、新しい実装を作成するときに、もう一度テストを書くことです。 サブクラスは特定の必須メソッドを呼び出しますか？ 特定のメソッドに特定の注釈がありますか？ メソッドAから期待される結果が得られますか？ メソッドBから期待される結果が得られますか？ このアプローチの利点を見ながら： テストを通じてサブクラスの要件を文書化します 問題のあるリファクタリングの場合、高速で失敗する可能性があります サブクラス全体とパブリックAPIを使用してテストします（「methodA（）は機能しますか？」ではなく、「このprotectedメソッドは機能しますか？」） 私が持っている問題は、新しいサブクラスのテストは基本的に簡単です：-テストはすべてのサブクラスですべて同じであり、メソッドの戻り値の型を変更するだけです（スケルトン実装はジェネリックです）。テストのアサート部分を確認してください。-通常、サブクラスにはそれらに固有のテストはありません テストがサブクラス自体の結果に焦点を当て、リファクタリングから保護する方法が好きですが、テストの実装が単なる「手動作業」になったという事実は、私が何か間違ったことをしていると思うようにします。 クラス階層をテストするときにこの問題は一般的ですか？どうすればそれを回避できますか？ ps：スケルトンクラスのテストについて考えましたが、抽象クラスのモックを作成してテストできるようにするのも奇妙に思えます。そして、サブクラスが予期していない動作を変更する抽象クラスのリファクタリングは、それほど速くは気付かれないと思います。私の勇気は、サブクラスを「全体として」テストすることがここで好ましいアプローチであることを教えてくれますが、間違っていると教えてください:) ps2：私はグーグルで調べて、このテーマに関する多くの質問を見つけました。そのうちの一つがこれ一つであり偉大な答えナイジェルソーンからの、私の場合は彼の「ナンバー1」になります それは素晴らしいことですが、この時点ではリファクタリングできないので、この問題に耐えなければなりません。リファクタリングできれば、各サブクラスを戦略として使用できます。それは問題ありませんが、「メインクラス」と戦略をテストしますが、メインクラスと戦略の統合を壊すリファクタリングは見当たりません。 ps3：抽象クラスをテストすることは「受け入れられる」という回答をいくつか見つけました。これは受け入れられることに同意しますが、この場合にどちらが好ましいアプローチであるかを知りたいと思います（私はまだ単体テストから始めています）

12 java  unit-testing  testing 

ユニットテストを書くときはいつでも、テストが失敗したときにデバッグを容易にするために、テストごとに1つのアサートをしようと常に試みてきました。しかし、この規則に従うと、各テストで同じコードを常にコピーしているように感じます。テストを増やすことで、読み取りと保守に戻るのが難しくなります。 シングルアサーションテストはDRYに違反していますか？ そして、メソッドごとに1つのテストを行うなど、良いバランスを見つけるために従うべき良いルールはありますか？* *私はおそらく、これに対するすべてのソリューションに適した1サイズではないことを認識していますが、これにアプローチする推奨方法はありますか？

12 testing  unit-testing  dry 

私の現在の仕事は、主に私たちが取り組んでいるさまざまなアプリケーションのGUIテストコードを書くことです。ただし、テスト内で多くのコードをコピーして貼り付ける傾向があることがわかりました。この理由は、テストしている領域は、繰り返しが必要なほど似ている傾向があるが、コードをメソッドまたはオブジェクトにカプセル化するほど似ていない傾向があるためです。クラスやメソッドをより広範囲に使用しようとすると、テストの保守が面倒になり、最初から書くのが完全に難しくなることがあります。 代わりに、通常、あるセクションからテストコードの大きな部分をコピーして別のセクションに貼り付け、必要な小さな変更を加えます。オブジェクト指向の原則や関数を使用するなど、構造化されたコーディング方法は使用しません。 テストコードを書くとき、他のコーダーはこのように感じますか？DRYとYAGNIの原則に従うことは明らかですが、テストコード（とにかくGUIテスト用の自動化されたテストコード）を使用すると、これらの原則に従うことが難しくなることがわかります。または、より多くのコーディングの練習とより良い全体的なシステムが必要ですか？ 編集：私が使用しているツールはSilkTestで、4Testと呼ばれる独自の言語です。同様に、これらのテストは主にWindowsデスクトップアプリケーション用ですが、このセットアップを使用してWebアプリもテストしました。

12 testing  code-quality  maintenance  test-automation 

私はJava 6 EEアプリケーションを開発しており、関数呼び出しのテストバージョンと元のコードで使用されているコードを使用してjspコードをテストしていますが、それは緩やかで非実用的です。この種のテストを達成する良い方法はありますか？

12 testing  programming-practices  unit-testing  java-ee 

私はほとんどのRoRプログラマーがテスト中毒者であり、大規模なテストスイートの利点を理解していますが、テストを開始したとき、そのような大規模なスイートを取得することはなく、「正しい方法でテストしていますか？本当に効率的ですか？」多くの場合、アプリケーションの動作のみをテストする統合テストを扱っています。 まず、テストする価値は本当にありますか？つまり、テストの作成に費やした時間は本当に価値があるのでしょうか？ 次に、RSpecを使用し、最近Cucumberを発見し、しばらく使用しましたが、これらすべての手順を書くことが本当に面倒な価値があるかどうかわかりませんか？私はステップを再利用できることは知っていますが、これらのステップが完了しすぎているかどうかはわかりません：たとえば、aを使用していますが、作成した場合にユーザーを複製する可能性があるためGiven I am logged in as (.+)、その定義で言う必要があるかどうかはわかりませんGiven there's a user called $1しかし、それは常に一歩前にある価値はありませんGiven I am logged in as (.+)。非常に多くのコードであり、おそらくほとんど役に立たないでしょう。毎日テストされた部品に新しいバグはないのではないかと思います...それで、CucumberはRSpecと比較して本当に価値がありますか？

12 unit-testing  testing  ruby-on-rails  cucumber 

私はヘルスケア事業向けの製品をテストしていますが、HL7メッセージを使用しています。HL7の問題について別の質問でうめき声をあげているが、詳細については言及していない。誰かが私たちが特に探しているべき問題や問題のクラスのアイデアを教えてもらえますか？ 解析によく使用されるライブラリを使用しています。これらの詳細や私たちがやっていることが役立つ場合は、コメントで知らせてください。できれば質問に追加します。

12 testing  parsing  hl7 

一般にソフトウェア開発とゲーム開発の違いについてこの論文を読んでいて、著者はソフトウェアテストに関していくつかの良い点を指摘しました。たとえば、 ...ゲーム開発者は、ゲームデザイナーの創造的な欲求の変化に直面して、これらのテストが急速に陳腐化するため、自動テストの使用をためらいます。 それで、この読書は、ゲームを扱っている/テストしているときに、ソフトウェアテストの他のどの側面を異なるまたは特定と見なすべきかを考えさせましたか？誰かがこれを経験したことがありますか、それについて何か他のことを聞いたことがありますか？

11 testing  game-development  acceptance-testing 

私は5チーム、合計約40人の開発者からなる開発グループの一員です。私たちは3週間のスプリントでスクラム方法論に従っています。継続的な統合セットアップ（Jenkins）があり、ビルドパイプラインには数時間かかります（広範な自動テストのため）。基本的に、開発プロセスはうまく機能します。 ただし、新しいスプリントを開始してから数日後、ビルドが不安定になり、スプリント終了の「コミットが停止する」まで揺れたままになることがあります。これの悪影響は、パイプラインのはるか下のビルドステップ、特にUI / Webtestsが数日間実行されないことです（「グリーン」ビルドでのみトリガーされるため）。その結果、新しく導入されたバグは、スプリントの非常に遅い段階でのみ検出されることがよくあります。 各コミットは、テストの基本セットに対して検証されます。確認されると、コードレビュー後に変更がマスターにプッシュされます（Gerrit） 基本的な単体テストは30分ごとに実行され、期間は10分未満です 統合テストは2時間ごと、1時間ごとに実行されます UI / Webtestsは、成功した統合テストで数時間実行されます スプリント中のビルドの安定性の責任者（スプリントごとに責任が渡される）によっては、ビルドを安定させるための中間的なアドホックな「コミット停止」が存在する場合があります。 だから、私たちが欲しい： 開発チームは、スプリント中に変更を開発してコミットします 後続のビルド結果にはほとんど意味がないため、ビルドステップが失敗した場合に放棄するビルドプロセス 開発者にタイムリーに質の高いフィードバックを提供するビルドプロセス （2）を考えると、ポイント（1）と（3）は互いに矛盾しているように見えます。誰もこれに対処する良い方法を持っていますか？ （現在、ポイント（2）を緩めており、失敗したビルドステップでもビルドの継続を許可しています。それが品質にどのように影響するかについて、まだフィードバックがありません。） ありがとう、サイモン

11 testing  scrum  code-quality  jenkins 

複数の開発者がいる分散システムを含むソフトウェア開発プロジェクトでは、論理および物理アーキテクチャの図を作成することがベストプラクティスですが、私の経験では、これらの図は常にプロジェクトの開始時に適切に管理されていますが、プロジェクトのリリース時に更新されませんメンテナンスフェーズが開始されます。 多くの分散プロセスを持つ複雑なプロジェクトの場合、最初のリリースの前であっても、誰も知識を持っていないため、ダイアグラムはすぐに古くなったり不正確になったりする傾向があります。 このような背景から、コミュニティに次の質問をしたいと思います。 正確で最新の論理および物理アーキテクチャ図を作成することはどれほど重要ですか？ それらを最新の状態に保つのに役立つツールやプロセスはありますか？ それらを最新の状態に保つ責任は誰にありますか？システム管理者、開発者、QAチームはどのように貢献できますか？

11 design  architecture  testing 

私は彼らが何を決定するのか理解していますが、見つかった問題にそれらを割り当てることは本当に便利ですか？つまり、すぐに修正する必要があるかどうかです。 それらの設定方法、分類方法などを知っています。IEEE/ ISOがそれを行う必要があることは知っています。理由がわかりません。

11 testing  reporting  defect 

私はこの質問で、関数型プログラマーは数学的な証明を使用して、プログラムが正しく機能していることを確認する傾向があることを読みました。これは、単体テストよりもずっと簡単で高速に聞こえますが、OOP /単体テストのバックグラウンドから来たので、一度も見たことがないです。 それを私に説明し、例を挙げてもらえますか？

11 testing  functional-programming