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

「適切な」方法でユニットテストを行う場合、つまり、すべてのパブリックコールをスタブ化し、プリセット値またはモックを返す場合、実際には何もテストしていないように感じます。文字通り、コードを見て、パブリックメソッドを通るロジックのフローに基づいて例を作成しています。そして、実装が変更されるたびに、それらのテストを行って変更する必要があります。これは、（中期でも長期でも）何か有用なことを達成しているとは感じません。また、統合テスト（非幸福なパスを含む）も行いますが、テスト時間が長くなることはあまり気にしません。それらで、私は実際に回帰をテストしているように感じます。なぜなら、それらは複数をキャッチしたからです。一方、ユニットテストは、パブリックメソッドの実装が変更されたことを示しています。 単体テストは広大なトピックであり、私はここで何かを理解していないと感じています。単体テストと統合テストの決定的な利点は何ですか（時間のオーバーヘッドを除く）。

59 testing  unit-testing  integration-tests 

午前中に到着すると、昨日の夕方に出発したときでもソフトウェアが機能しなくなっていることがわかります。 職業はなんですか？最初に何を確認しますか？怒りを止めて問題に取り組むために何をしますか？あなたは同僚を非難し、彼らに直接行きますか？そのような状況に陥ることを避けるために何ができますか？

59 testing  debugging 

私はソフトウェア開発者です。アナリストによって書かれたテストケースをフォローして実行するが、探索的テストも実行するテスターのチームがあります。テスターは誰がより多くのバグを開くかを競い合っているようで、バグレポートの質が低下していることに気づきました。機能のテストやソフトウェアの動作に関連するバグの報告の代わりに、テスターは画面の機能強化、使いやすさ、または愚かなバグに関するバグを提出しています。 これはプロジェクトに適していますか？そうでない場合、どうすれば（ソフトウェア開発者として）テスターチームの考え方や態度を変えようとすることができますか？ もう1つの問題は、期限が推定されて変更できないため、期限が近づくと、テスト担当者がテストケースを終了するためにスクランブルし、テストの品質が低下することです。これにより、クライアントが受け取った最終製品に正当なバグが発生します。 OBS：この競争は会社の慣行ではありません！それは彼らによって組織されたテスターだけの間の競争であり、賞はありません。

54 programming-practices  testing  project-management 

この回答へのコメントを読む、具体的には： テストを書くことができないからといって、テストが壊れていないわけではありません。通常、期待どおりに動作する未定義の動作（CおよびC ++はそのすべてで満たされています）、競合状態、メモリモデルの弱さによる潜在的な再配列... – CodesInChaos 7時間前 @CodesInChaos再現できない場合、「修正」に書き込まれたコードもテストできません。未テストのコードを公開することは、私の意見では最悪の犯罪です– RhysW 5時間前 ...テストケースの競合状態が原因で、本番環境で非常にまれにしか発生しない問題を一貫して引き起こす良い一般的な方法があるかどうか疑問に思っています。

54 testing  multithreading 

飛行機は、たとえばウェブサイトとは対照的に、特定のシステムの障害が完全に受け入れられないシステムです。飛行監視などのエラーにより、自動操縦装置が誤作動して潜水する可能性があるためです。明らかに、これは、ボーイングとエアバスの優秀なエンジニアがオートパイロットをチェックして、ダイビングが完全に受け入れられ安全な操縦であると突然判断しないことを確認しているために起こりません。または、コンピューターがクラッシュし、新しいフライバイワイヤー航空機のパイロットが飛行機を実際に飛行できなくなった可能性があります。もちろん、（ソフトウェアと航空機の両方の）クラッシュを防ぐために、これらのシステムにはさまざまな安全手順と冗長性が組み込まれています。 ただし、一方で、ソフトウェアが完璧ではないことは明らかです。オープンソースとクローズドソースの両方のソフトウェアは定期的にクラッシュし、最も単純な「Hello World」プログラムだけが失敗しません。航空、医療、その他の生死の業界でソフトウェアシステムを設計するエンジニアは、ソフトウェアが失敗しないようにテストできます（失敗した場合、少なくとも正常に失敗します）。 「みんな、ボーイング/エアバス/（他の会社）で働いていますが、そうではありません！次のフライト/病院訪問で楽しんでください。」

51 testing 

アサートと単体テストの両方は、コードベースのドキュメントとして、またバグを発見する手段として機能します。主な違いは、アサートが健全性チェックとして機能し、実際の入力を確認するのに対して、ユニットテストは特定のシミュレートされた入力で実行され、明確に定義された単一の「正しい答え」に対するテストです。正当性を検証する主な手段として、アサーションと単体テストを使用する相対的なメリットは何ですか？どちらをもっと強調すべきだと思いますか？

51 testing  unit-testing  assertions 

いくつかのソフトウェアプロジェクトの作業中にパターンに気付きました。報告されたバグの大部分は、優先度が非常に高い/非常に高いものでした。私は何人かの同僚になぜこれが起こっているのかと尋ねましたが、バグがその優先度を持たない場合、バグが開発者の注意を引くことは非常にまれであると述べました。 ですから、この問題が一般的なのか、それとも運が悪かったのかを知りたいと思いました。Googleで簡単に検索したところ、一部のチームがバグ報告ガイドラインを実装しているか、別の「バグトリアージ」チームを持っていることがわかりました。この問題に直面して解決した場合、どのアプローチが効果的でしたか？ この質問は、具体的には「優先インフレ」問題に関するものです。シナリオに直面した場合、およびこの問題に対してどのような対策が効果的か。

50 testing  bug-report 

65.000.000.000テストのスイートを実行する方法について尋ねられたので、このような膨大なテストを含むプロジェクトがあるのは普通かと思います。 この特性を持つプロジェクトで働いたことはありますか？

50 testing  unit-testing  continuous-integration 

このサイトには、自動テストから得られる利点に関する多くの情報を提供する多くの質問があります。しかし、私はコインの反対側を表すものを見ませんでした：欠点は何ですか？人生のすべてはトレードオフであり、特効薬はありませんので、自動テストを行わない正当な理由が必ずあるはずです。彼らは何ですか？ ここに私が思いついたいくつかがあります： 特定の機能に対して初期開発者の時間がさらに必要です チームメンバーの高いスキルレベルが必要 ツールのニーズを増やす（テストランナー、フレームワークなど） 失敗したテストが発生した場合に必要な複雑な分析-このテストは私の変更により廃止されたのですか、それとも間違いを犯したと言っているのですか？ 編集 私は自動化されたテストの巨大な支持者であると言っておくべきであり、私はそれをすることを納得させるつもりはありません。欠点が何なのかを理解したいと思っているので、会社に行って主張するとき、次の想像上の銀の弾丸を投げているようには見えません。 また、上記の私の例に異議を唱える人を探していないことを明確にしています。私は、いくつかの不利な点（すべてにトレードオフがある）がなければならないことを真実と考えており、それらが何であるかを理解したいと思います。

49 testing  unit-testing  tdd  automation  test-automation 

私のプログラムの統合テストがすでにあり、それらすべてが合格した場合、それはうまくいくと感じています。次に、単体テストを作成/追加する理由は何ですか？とにかく統合テストを書く必要があるので、統合テストでカバーされていない部品の単体テストのみを書きたいと思います。 統合テストよりも単体テストの利点を知っているのは 小さく、したがって高速に実行できます（ただし、テストに新しいユニットを追加すると、統合テストで既にテストされているため、テストスーツ全体が大きくなり、実行時間が長くなります） 1つのことしかテストしないため、バグを見つけやすくなります（ただし、統合テストが失敗した場合は、個々のパーツを検証するために単体テストの書き込みを開始できます） 統合テストで検出されない可能性のあるバグを見つけます。たとえば、マスキング/オフセットのバグ。（ただし、統合がすべてのパスをテストする場合、プログラムは隠れたバグが存在する場合でも動作します。したがって、将来の統合テストを中断したり、パフォーマンスの問題を引き起こさない限り、これらのバグを見つける/修正することは優先度が高くありません） そして、私たちは常により少ないコードを書きたいのですが、単体テストを書くにはもっと多くのコードが必要です（主にモックオブジェクトをセットアップします）。単体テストと統合テストのいくつかの違いは、単体テストではモックオブジェクトを使用し、統合テストでは実際のオブジェクトを使用することです。重複が多く、コードの動作を変更するためのオーバーヘッドが追加されるため、テストでもコードの複製は好きではありません（リファクタリングツールは常にすべての作業を行うことはできません）。

47 testing  unit-testing  tdd  integration-tests 

ソフトウェアエンジニアリングでは、バグを修正するコストが、バグが発見された後の開発で指数関数的に増加することはよく知られています。これは、Code Completeで公開され、他の多くの出版物で採用されているデータによってサポートされています。 ただし、このデータは存在しなかったことがわかります。Code Completeが引用したデータは、明らかにそのようなコスト/開発時間の相関関係を示しておらず、同様の公開された表は、いくつかの特殊なケースで相関関係を示しました。 これを裏付ける、または反論する独立したデータはありますか？ そして、もし本当なら（つまり、発見された最近のバグのためにこの指数関数的に高いコストをサポートするデータがない場合）、これはソフトウェア開発方法論にどのように影響しますか？

45 testing  development-process  debugging 

私は比較的新しいソフトウェア開発者であり、改善すべきと思うことの1つは、自分のコードをテストする能力です。新しい機能を開発するたびに、バグを見つけるために、考えられるすべてのパスをたどることは非常に困難です。私はすべてがうまくいく道をたどる傾向があります。これはプログラマーがよく知っている問題であることは知っていますが、現在の雇用主にはテスターがいないので、同僚はこれにかなり優れているようです。 私の組織では、テスト駆動開発もユニットテストも行っていません。それは私を大いに助けますが、これが変わる可能性は低いです。 これを克服するために私にできることは何ですか？独自のコードをテストするとき、どのアプローチを使用しますか？

45 testing 

これまでのところ、テスト駆動開発を理解しているので、失敗した（赤の）単体テストがある場合にのみ生産的なコードを書くことができます。これに基づいて、テスト駆動アプローチを他の形式のテストにも適用できるかどうか疑問があります。

41 testing  tdd 

PDFファイルを処理する機能のテストコードを書いています。テストの背後にある基本的な考え方は、特別に選択したいくつかのPDFにそれらを向け、それらを処理し、出力が期待どおりであることを確認することです。 私の質問は、これらの大きなPDFをどこに保存すればよいのかということです。コードとともにバージョン管理にチェックインする必要がありますか？または、それらを別の場所に配置しますか？明らかに、テストコードはPDFなしでは（または異なるPDFでさえ）役に立たないのですが、それでもリポジトリにそれらを入れることは間違っていると感じています。

40 testing  version-control  data 

今日、私たちはTDDをトレーニングしていて、次の誤解のポイントを見つけました。 タスクは、入力 "1,2"が3である数値の合計を返すためのものです。（C＃で）私が書いたのは： numbers = input.Split(','); return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct しかし、他の人はそれを別の方法で行うことを好みました。まず、入力 "1,2"について、次のコードを追加しました。 if (input == "1,2") return 3; 次に、入力 "4,5"のテストをもう1つ導入し、実装を変更しました。 if (input == "1,2") return 3; else if (input == "4,5") return 9; そしてその後、彼らは「さて、今はパターンが見える」と言って、私が最初にやったことを実装しました。 2番目のアプローチはTDDの定義により適していると思いますが、...厳密にすべきでしょうか？私にとっては、些細な赤ちゃんのステップをスキップして、何もスキップしないことを十分に確信している場合は、それらを「ツインステップ」に結合してもかまいません。私が間違っている？ 更新。私はそれが最初のテストではないことを明確にしないことで間違いを犯しました。すでにいくつかのテストが行​​われているため、「return 3」は実際に要件を満たすための最も単純なコードではありませんでした。

37 testing  tdd