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

クラスの2つのメソッドのテストがあるとします。最初の方法では、別の層からデータを収集し、ランタイムに依存しない何らかの種類のストレージ（SQLテーブルなど）に格納するため、このテストで処理されるすべてのデータはテストにハードコーディングされます。2番目のメソッドは、最初のメソッドがデータを残した場所からデータを取得し、何らかの方法で変換（計算、特定の部分を他の場所に移動するなど）を担当します。 この2番目の方法では、最初の方法と同様に入力をハードコーディングするか、2つのテストを連続して実行し、最初のテストで実際に保存されたデータを取得して、1番目のテストが中断した場所から再開できると想定できます。 2番目のオプションを選択した場合、2つの方法がうまく機能するというのは本当に良い考えですが、1番目のテストが失敗した場合、それ以降のすべてのテストは失敗し、バグをより迅速に特定するのに役立つテストの利点がなくなります。 最初のオプションを選択した場合、各メソッドは独立して分離され、テストされますが、それらが実際に適切に連携できることを本当に知ることはありません。 ここでより良いオプションはどれですか？ハードコーディングを使用して分離されたメソッドごとに単一のテストを実行し、次に両方のメソッドを1つに含むより大きなテストを実行するなど、何らかの方法がありますか？

24 testing  unit-testing  tdd 

私は現在、学期プロジェクトのために、単体テストや統合テストなど、複数のタイプのテストを実行する必要があるソフトウェアテストのクラスにいます。統合テストの場合、教授は統合テストにモックとモック作成ライブラリ（EasyMockやMockitoなど）を使用すると言いました。私はかなり混乱しています。統合テストとは、クラス、モジュール、サービスなどの外部をテストすることです。複数のクラスとサービスをテストする場合、統合テストでモックとスタブを使用するのが適切なのはなぜですか？

24 unit-testing  testing  integration-tests  mocking 

Joel Spolskyが書いたこのブログを読んで、コードを改善するための12の手順を説明しました。テスト駆動開発の欠如は本当に驚きました。だから私はグルに質問を投げたい。TDDは本当に努力する価値はありませんか？

23 programming-practices  testing  code-quality  tdd 

iPhone用に1つのアプリケーションを開発しましたが、今ではApp Storeでそれを求めています。私のiOSオタクの友人の多くは、実際のデバイス、つまりiPhoneでテストするように言った。 だから私は実際のiPhoneデバイスで私のiPhoneアプリをテストする必要があるのだろうか？彼らは（Apple）が私のデバイスとほぼ同じ「シミュレータ」を与えているのですか？

23 testing  iphone  ios 

私は多くの異なる言語で多くのソフトウェアを書きました。また、VerilogとVHDLを使用してFPGAで使用するハードウェアを「書きました」。 私はソフトウェアよりもハードウェアを書くことを楽しむ傾向があり、主な理由の1つは、「完了」して変更する必要のないハードウェアを書くことができるからだと思います。インターフェイスと機能を定義し、テストベンチを書く、ハードウェアモジュールを実装してから、シミュレータを使用してそれをテストします。次に、そのハードウェアモジュールをビルディングブロックとして使用して、より大きくより良いものを作成できます。そのモジュールに機能を追加する必要がある場合は、2番目のモジュールを作成し、そこに機能を追加します。元のモジュールは問題なく機能し、引き続き有用であるため、元のモジュールを捨てることはありません。 ソフトウェアに関する私の主な不満の1つは、「完了」しないことです。追加する別の機能が常にあります。多くの場合、機能を追加すると、以前は正常に機能していた別の場所にバグが発生します。これは、インターフェイスに違反していない限り、ハードウェアでは発生しません。 明確にするために、機能のリストを使用して何かの1つのバージョンを構築することを支持していません。それは永遠です。左側のコードを突いて右側のバグを見つけたくないのですが、これは新しい機能を追加した後に起こるようです。 ハードウェアが「書き込まれる」のと同様の方法でソフトウェアを書くことは可能ですか？既存のコードを書き直したり新しいバグを導入したりすることなく、常に前進を続け、新しい機能を追加できる優れたソフトウェア開発方法論はありますか？

23 architecture  testing  development-methodologies 

現在、自動化されたユーザーインターフェイステストを調査中です（現在、自動化された単体テストと統合テストを行っています）。 SeleniumとTelerikを見てきましたが、後者の方がはるかに柔軟なレコーダであるため、後者を選択のツールとして採用しました。テスターがあまり多くのコードを書くことは望ましくありません。 ただし、全体的なメリットを理解しようとしています。人々の意見はどのようなもので、どのようなものがうまく機能し、何がうまくいかないのでしょうか？ 私たちのシステムは絶えず開発されており、（ウェブベースの）プラットフォームの新しいバージョンを定期的にリリースしています。 これまでのところ、主な利点は、特にプラットフォームの複数のクライアント展開での回帰テストにあります。 他の人の意見を本当に探しています。私たちはそれが正しいことだと「考える」が、すでに忙しいスケジュールの中で、さらなる洞察を探している。

23 testing  user-interface  selenium  test-automation  telerik 

これは非常に基本的な質問です。一部のソフトウェアアプリケーションには、アプリケーションのテストケースがほぼ無限に多数あります。これらすべてのテストケースをテストすることは実用的ではありません。テストをいつ停止するかをどのように決定しますか？（「お金がなくなったとき」を除く）。

23 testing  development-process 

ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私は過去4年半にわたってエンタープライズの分野で働いてきましたが、一般的に言って、エンタープライズはテストファーストスタイルの開発を促進する環境ではないことに気付きました。プロジェクトは通常、固定コスト、固定タイムライン、およびウォーターフォールスタイルです。ユニットテストが行​​われたとしても、通常はQAフェーズでの開発後に別のチームによって行われます。 企業で働く前に、私は多くの中小企業に相談しましたが、テストファーストスタイルの開発プロジェクトにお金を払うつもりはありませんでした。彼らは通常、開発をすぐに開始するか、短い設計期間の後、つまりアジャイルに似たものを望んでいましたが、一部のクライアントはすべてがウォーターフォールのようにマッピングされることを望みました。 テスト駆動開発は、どのタイプのショップ、企業、クライアントで最も効果的ですか？どのタイプのプロジェクトがTDDを助長する傾向がありますか？

23 testing  agile  unit-testing  tdd 

私たちは、同じgitリポジトリで複数のプロジェクトに取り組んでいる大きなチーム（10〜12人の開発者と4人のqa）です。そのスプリングブートベースのバックエンドWebサービス。優れたgit分岐および展開戦略を探しています。また、機能が期待どおりに機能することを保証するqaチームもあります（ある程度のバグはありません）。 いくつかの記事を読んだ後、Gitflowモデルは私たちにとってうまく機能するだろうと感じました。ここに私の質問が来ます。 QAチームはどこで機能をテストする必要がありますか？ 彼らが機能ブランチでテストすれば、彼らはバグを発生させ、開発者はそれを修正し、それがQAテストに合格したら、開発のためにマージします。また、QAは開発ブランチで整数化テストを再度行います。 すべての機能をマージして（ユニットテストと開発者による基本的なテストの後）ブランチを開発し、そこからqaテストを行います。修正とテストもすべて開発中に行われます。 他の人にとってどのアプローチがうまくいったのか知りたいです。

23 testing  git  branching  qa  gitflow 

私はソフトウェアエンジニアではありません。私は地球科学の分野で博士課程の学生です。 ほぼ2年前、科学ソフトウェアのプログラミングを開始しました。継続的インテグレーション（CI）を使用したことはありません。主に、最初はそれが存在することを知らず、このソフトウェアに取り組んでいるのは私だけだったからです。 現在、ソフトウェアのベースが実行されているため、他の人がそれに興味を持ち始め、ソフトウェアに貢献したいと考えています。計画では、他の大学の他の人がコアソフトウェアへの追加を実装しています。（バグが発生する可能性があります）。さらに、ソフトウェアは非常に複雑になり、テストがますます難しくなりました。また、作業を継続する予定です。 この2つの理由により、私はCIの使用についてますます考えています。私はソフトウェアエンジニアの教育を受けたことがなく、CIについて聞いたことがありません（私たちは科学者であり、プログラマーではありません）。 私はいくつかのアドバイスを得たい質問がいくつかあります： まず、ソフトウェアの動作の簡単な説明： ソフトウェアは、必要なすべての設定を含む1つの.xmlファイルによって制御されます。入力引数として.xmlファイルへのパスを渡すだけでソフトウェアを起動すると、実行され、結果を含むいくつかのファイルが作成されます。1回の実行に最大30秒かかります。 科学的なソフトウェアです。ほとんどすべての関数には複数の入力パラメーターがあり、そのタイプはほとんどが非常に複雑なクラスです。これらのクラスのインスタンスを作成するために使用される大きなカタログを持つ複数の.txtファイルがあります。 では、私の質問に行きましょう。 ユニットテスト、統合テスト、エンドツーエンドテスト？：私のソフトウェアは現在、約30.000行のコードで、数百の関数と〜80クラスです。すでに実装されている数百の関数の単体テストの作成を開始するのは、ちょっと奇妙に感じます。だから私は単にいくつかのテストケースを作成することを考えました。10〜20個の異なる.xmlファイルを準備し、ソフトウェアを実行します。これがエンドツーエンドテストと呼ばれるものだと思いますか？私は頻繁にこれを行うべきではないことを読みましたが、すでに動作するソフトウェアをお持ちの場合、それはスタートとして大丈夫ですか？または、すでに動作しているソフトウェアにCIを追加しようとするのは、単純な馬鹿げたアイデアでしょうか。 関数パラメーターを作成するのが難しい場合、単体テストをどのように作成しますか？ 私は機能を持っていると仮定double fun(vector<Class_A> a, vector<Class_B>)し、通常、私はタイプのオブジェクトを作成するために複数のテキストファイル内の最初の読み取りに必要があるだろうClass_AとしClass_B。Class_A create_dummy_object()テキストファイルを読み取らずにダミー関数を作成することを考えました。また、何らかのシリアル化の実装についても考えました。（クラスオブジェクトは複数のテキストファイルにのみ依存するため、クラスオブジェクトの作成をテストする予定はありません） 結果が大きく変動する場合のテストの書き方 私のソフトウェアは、大きなモンテカルロシミュレーションを利用し、繰り返し動作します。通常、1000回の反復があり、反復ごとに、モンテカルロシミュレーションに基づいてオブジェクトのインスタンスを500〜20.000個作成しています。1つの反復の1つの結果のみが少し異なる場合、今後の反復全体が完全に異なります。この状況にどのように対処しますか？最終結果は非常に変動するので、これはエンドツーエンドのテストに対する大きなポイントだと思いますか？ CIに関するその他のアドバイスは大歓迎です。

22 object-oriented  c++  testing  continuous-integration 

すべてまたはほとんどのコーディングがスプリントの終了まで行われない場合、テストはコーディングと同じスプリント内でどのように処理されますか？（スプリント内の単一のPBIの「スープからナッツ」への開発とテストに言及しています。） 私がオンラインで見た回答のほとんどはQAの自動化に関係していますが、自動化されたテストを記録または作成するための機能的なUIが一般的に必要なので、それも実際には不可能です。機能を開発し、新しい要件を発見するにつれて進化し続けるストーリーボードしかありません。 私の場合、新しいデスクトップアプリケーションを開発しています。通常、デスクトップアプリは自動テストにあまり適していません。自動化された単体テストがいくつかありますが、QAの専門家が行う手動の機能/統合テストではありません。 ですから、私が今いるのは、私のスプリントが明日で終了するということです、私はまだコーディングを終える必要があります、そして私のQAの人々はまだテストするものが何もありません、そして私が手を持たずに私が彼らに与えるものをテストする方法がわかりません。 私はこのジレンマを持っている最初の人ではないと確信しています。 過去に、パイプラインを実行しました。現在のスプリントでは、テストチームが前のスプリントで実装された機能をテストします。私の現在の仕事では、PMはこのアプローチを「ウォーターフォール」と呼んでいます。

22 agile  testing  unit-testing  scrum  qa 

私は中規模企業のソフトウェアエンジニアです。TeamCityで実行されるかなり堅牢なテストプラットフォームがあります。すべてのチェックインで単体テストを実行し、毎日の単体テスト/ BVTを実行します。 問題は、大量の単体テストが失敗していることです。 ユニットテストが絶えず壊れていて、メンテナンスされていない場合、かなり頻繁にユニットテストの無意味さを引き出します。変更によってリグレッションが発生したかどうかを確認できないと、単体テストプラットフォームの価値のほとんどが失われます。 良い習慣の文化を作り出す種を植えたいです。壊れたときにテストを修正し、それらを価値あるものとみなし、他の作業とともにテストの修正を優先します。 私は賄ber（焼き菓子！）を試みましたが、単純に尋ねて、チームリーダーに話しました。誰もがそれは良いアイデアだと言いますが、私はそれについて何かをしている唯一の人であると思います。 他の人にテストの修正を奨励し、スプリント内でのテスト修正の優先順位付けを開始する最良の方法は何ですか？ これを尋ねる主観的な方法がなければ、どんなヒントでも喜んで受け入れます。

22 testing  unit-testing  tdd  culture  leadership 

ほとんどのソフトウェア開発者が同意する数少ない点の1つは、テストしない限り、正しく動作するためにコードに依存すべきではないということです。あなたがそれをテストしないなら、それはあなたが将来さらに仕事をすることになるだけの隠れたバグを持っているかもしれません。 通常のコードのテスト方法は理解していますが、テストコードをテストして、エラーが存在する場合に効果的にエラーを見つけて報告できることを確認するにはどうすればよいですか？私は個人的には、あるべきではないときに合格する誤ったテストケースを書くほど愚かであり、そもそも筆記テストの目的を破っています。幸いなことに、私は時間内にエラーを見つけて修正しましたが、テストのマントラによれば、それが機能することを確認するための独自のテストセットがなければ、テストスイートは完成しないようです。 これを行うための最良の方法は、バグのあるコードのテストが失敗することを確認することだと思われます。テストは「動作」します。これにより、2番目の質問が表示されます。テストケースでバグを確実にキャッチするために、バグを導入する良い方法は何ですか？文をランダムにコメントアウトしif-else、条件を否定して間違ったブランチを実行することを確認し、副作用などでコードの実行順序を変更して、テストが最もキャッチされるようになるまで一般的なバグ？プロの開発者は、テストが実際に行うべきことを実際に行うことをどのように検証しますか？彼らは単にテストが機能すると仮定していますか、それともテストにも時間をかけていますか？もしそうなら、彼らはどのようにテストをテストしますか？ 私は、人々がテストをテストし、実際に実際のコードを書くことのないテストのためにテストをテストするのにそれほど多くの時間を費やすべきだと提案しているわけではありませんが、 「メタテスト」の、そしてそれを行うための最良の方法に興味がありました。：D *「バグのない」コードをテストするときにテストが合格するかどうかを確認できましたが、テストの仕様としてコードを使用することはかなり逆に思えます...

22 testing  unit-testing  code-quality 

テスト中にエラーが発生するテスターがいますが（これまでのところ）、すぐに頻繁に報告します。私たち（開発者）は、テスターが問題を再現しようとしておらず、（尋ねられたときに）問題を再現する方法を見つけることができないことを後で発見します。 今、これらはまだバグです、私はそれらを無視したくありません。しかし、再現手順がないと、ちょっと行き詰まります。スタックトレースがある場合もあります（ただし、これはコンパクトなフレームワークであり、行番号がないため、しばしば有用ではありません）。しかし、ある場合、スタックトレースを取得してコードをクラックし、推測を開始できますが、テスト可能な「修正」にはつながりません。 このようなシナリオでは何をしますか？

22 bug  testing 

比較的大きくて古いコードベースで、既に定義されているインターフェイス（C ++ヘッダーファイルのセット）を再実装するタスクを引き受けようとしています。これを行う前に、可能な限り完全なテストカバレッジを取得したいので、再実装エラーをできるだけ早く簡単に検出できます。問題は、既存のコードベースが、（非常に）大規模なクラスと関数、高度な結合、（多くの）副作用を伴う関数などで簡単にテストできるように設計されていないことです。 同様のタスクの以前の経験や、自動化されたテスト（ユニット、統合、回帰など）をレガシーコードにどのように改良したかについての良い具体的なヒントを聞いていただければ幸いです。

22 testing  legacy