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

そのシステムの予想される動作に対するソフトウェアシステムの動作の確認。

21
テスターが見つけるためのコードに意図的なバグを残す
弊社ではこれを行っていませんが、友人の一人が、プロジェクトマネージャーがすべての開発者に、製品がQAに移行する直前に意図的なバグを追加するように依頼したと言います。これがどのように機能するかです: 製品がQAに移行する直前に、開発チームはコードのランダムな場所に意図的なバグを追加します。これらのバグが最終製品に付属していないことを確認するために、元の動作中のコードを適切にバックアップします。 テスターに​​もこのことが通知されます。バグが存在し、それらを見つけられないことは無能の兆候と見なされる可能性があることを知っているため、彼らは一生懸命テストします。 バグ(意図的またはその他)が見つかった場合、それらは開発チームが修正するために報告されます。開発チームは、製品が第2レベルのQAに移行する直前に、コードの関連セクションに別の意図的なバグを追加します。プロジェクトマネージャーは、テスターは開発者のように考えるべきであり、変更が行われたセクションに新しいバグがあることを期待すべきだと言います。 まあ、これはそれがどのように行くかです。彼らは、このアプローチには次の利点があると言っています。 テスターは常につま先を向いており、狂ったようにテストします。これは、開発者が修正できるように、隠れた(意図しない)バグを見つけるのにも役立ちます。 テスターはバグをフィードします。バグを見つけられないと、彼らの士気に影響します。ですから、彼らに見つけやすいものを与えることは彼らの士気を助けるでしょう。 これらの意図的なバグの1つが最終製品に同梱されるシナリオを無視する場合、このアプローチの採用を検討する前に考慮すべきその他の欠点は何ですか? いくつかの説明: ソース管理で元のコードを適切にバックアップします。 テスターが意図的なバグを見つけると、開発チームはそれを無視します。テスターが意図しない(元の)バグを見つけた場合、開発チームは最初に意図的なバグが原因かどうかを確認します。つまり、開発チームは最初に元の作業コードでそれを再現しようとし、可能な場合は修正しようとします。 QAと開発チームの関係の問題を無視してください。私は、ワークプレイスではなくプログラマーにこの質問を具体的に尋ねました。QAと開発チームの間には良好な関係があり、勤務時間後には一緒にパーティーを行うことを考慮してください。プロジェクトマネージャーは、両方のチーム(Godsend)をサポートする準備が常にできている、素晴らしく、年配の紳士です。

9
テストを書くのに実際のコードと同じくらいの時間を費やすのは普通ですか?
テストは、テストしている実際のコードよりもはるかに複雑で記述しにくいと感じています。テストしているコードよりもテストの作成に多くの時間を費やすことは珍しくありません。 それは正常ですか、何か間違っていますか? 質問「単体テストまたはテスト駆動開発は価値がありますか?」、「システム自体の実装よりも機能テストの実装に多くの時間を費やしていますが、これは正常ですか?」と彼らの答えは、テストに値するかどうかについての詳細です(「テストを完全に省略する必要がありますか?」)。テストは重要だと確信していますが、実際のコードよりもテストに多くの時間を費やすのが普通なのか、それとも私だけなのか疑問に思っています。 受け取った質問の意見、回答、賛成票の数から判断すると、ウェブサイト上の他の質問では扱われていない正当な懸念があると推測できます。


30
開発者に遅い開発マシンを与えると、コードはより速く/より効率的になりますか?[閉まっている]
開発者に絶叫する高速マシンを提供するとします。WPFベースのVS2010は非常に高速にロードされます。次に、開発者は、自分のボックスで正常に動作するWPFまたはWPF / eアプリケーションを作成しますが、現実の世界でははるかに低速です。 この質問には2つの部分があります... 1)開発者に遅いマシンを提供するということは、結果のコードがより高速またはより効率的であることを意味しますか? 2)開発者に高速のIDEエクスペリエンスを提供し、「典型的な」ランタイムエクスペリエンスを提供するにはどうすればよいですか? 更新: 記録のために、経営陣に対して率直な対応を準備しています。これは私の考えではありません。あなたの人々は、クライアントの誤った要求を修正するのを手伝っています。より多くの弾薬と、これにいつどこでアプローチするかについて言及してくれてありがとう。次のような有効なユースケースを+1しました。- 特定のサーバー側プログラミングの最適化 -テストラボ - 最高品質のグラフィックカードではなく、より良いサーバーを購入する可能性
130 ide  testing  performance 

10
ランダム性をテストするにはどうすればよいですか?
配列内の要素をランダムにシャッフルする方法を検討してください。これが機能していることを確認するために、シンプルでありながら堅牢な単体テストをどのように作成しますか? 私は2つのアイデアを思いつきましたが、どちらにも顕著な欠陥があります: 配列をシャッフルし、順序が以前と異なることを確認します。これは良いように聞こえますが、シャッフルが同じ順序でシャッフルされると失敗します。(ありえませんが、可能です。) 一定のシードで配列をシャッフルし、所定の出力に対してチェックします。これは、同じシードが与えられると常に同じ値を返すランダム関数に依存しています。ただし、これは無効な仮定である場合があります。 サイコロの出目をシミュレートし、乱数を返す2番目の関数を考えます。この機能をどのようにテストしますか?その機能をどのようにテストしますか... 与えられた範囲外の数値を返すことはありませんか? 有効な分布で数値を返しますか?(1つのダイスで均一、多数のダイスで通常)。 これらの例だけでなく、一般的なコードのランダム要素をテストするための洞察を提供する回答を探しています。ユニットテストはここでも正しい解決策ですか?そうでない場合、どのようなテストがありますか? みんなの心を楽にするためだけに、私は自分の乱数ジェネレーターを書いていません。

7
単体テストで何をテストする必要がありますか?
私は大学を卒業したばかりで、来週どこかで大学を始めています。単体テストを見てきましたが、あまり使用しませんでした。誰もがそれらについて話すので、私はいくつかのことをすべきだと思いました。 問題は、何をテストすべきかわからないことです。一般的なケースをテストする必要がありますか?エッジケース?機能が適切にカバーされていることを知るにはどうすればよいですか? 特定のケースで機能が機能することをテストで証明することはできますが、機能が機能することを証明することはまったく役に立たないという恐ろしい気持ちが常にあります。

11
(データベース)統合テストは悪いですか?
一部の人々は、統合テストはすべての種類の悪い点と間違っていると主張しています -すべてを単体テストする必要があります。さまざまな理由で、私は常に好きではないオプション。 場合によっては、単体テストでは何も証明されないことがわかります。 例として、次の(PHPでの)単純な(単純な)リポジトリー実装を取り上げましょう。 class ProductRepository { private $db; public function __construct(ConnectionInterface $db) { $this->db = $db; } public function findByKeyword($keyword) { // this might have a query builder, keyword processing, etc. - this is // a totally naive example just to illustrate the DB dependency, mkay? return $this->db->fetch("SELECT * …

7
統合テストとは正確には何ですか?
私の友人と私は、統合テストとは何かを正確に分類するのに苦労してきました。 今、家に帰る途中で、統合テストの実世界の例を挙げようとするたびに、それが受け入れテストであることがわかりました。事業者が大声で言うことで、システムが何を提供すべきかを特定します。 これらのテストタイプの分類についてRuby on Railsのドキュメントを確認しましたが、今では完全にスローされています。 統合テストの簡単なアカデミックな説明を実際の例で教えてもらえますか?
110 testing  agile  tdd 

12
テスト可能なコードはより良いコードですか?
私は自分のコードで定期的にユニットテストを書く習慣を身につけようとしていますが、最初に読んだのはテスト可能なコードを書くことです。 この質問は、テスト可能なコードを作成するという固い原則に触れていますが、テストの作成をまったく計画せずに、それらの設計原則が有益である(少なくとも害がない)かどうかを知りたいです。明確にするために-テストを書くことの重要性を理解しています。これは、それらの有用性に関する質問ではありません。 私の混乱を説明するために、この質問に影響を与えた作品で、ライターは現在の時刻をチェックし、時刻に応じて値を返す関数の例を示します。作成者は、内部で使用するデータ(時間)を生成するため、テストが困難になるため、これを不良コードと指摘します。私にとっては、しかし、引数として時間を渡すことはやり過ぎのようです。ある時点で、値を初期化する必要がありますが、なぜ消費に最も近いのではありませんか?さらに、私の考えでは、このメソッドの目的は、現在の時刻に基づいて何らかの値を返すことであり、この目的を変更できるかどうかを示すパラメータにすることです。これと他の質問は、テスト可能なコードが「より良い」コードと同義語かどうか疑問に思います。 テストがない場合でも、テスト可能なコードを書くことはまだ良い習慣ですか? テスト可能なコードは実際にはより安定していますか?重複として提案されています。ただし、その質問はコードの「安定性」に関するものですが、読みやすさ、パフォーマンス、結合など、他の理由でもコードが優れているかどうかについてより広くお尋ねしています。

11
(なぜ)単体テストが依存関係をテストしないことが重要ですか?
自動化されたテストの価値を理解し、問題が十分に特定されていて、良いテストケースを思いつくことができる場所ならどこでもそれを使用します。ただし、こことStackOverflowの一部の人々は、依存関係ではなくユニットのみをテストすることを強調していることに気付きました。ここでは、利益が見られません。 テストの依存関係を回避するためのモッキング/スタブ化は、テストを複雑にします。実稼働コードに人為的な柔軟性/デカップリング要件を追加して、モックをサポートします。(これは良いデザインを促進すると言う人には賛成できません。余分なコードを書いたり、依存性注入フレームワークのようなものを導入したり、コードベースに複雑さを加えて実際のユースケースなしで物事をより柔軟/プラグ可能/拡張可能/分離することは、オーバーエンジニアリングではなく、良いデザイン。) 第二に、依存関係のテストとは、どこでも使用される重要な低レベルコードが、テストを明示的に考えた人以外の入力でテストされることを意味します。依存する低レベルの機能をモックアウトせずに、高レベルの機能で単体テストを実行することで、低レベルの機能に多くのバグを発見しました。理想的には、これらは低レベル機能の単体テストで発見されたはずですが、見逃されたケースは常に発生します。 これの反対側は何ですか?単体テストが依存関係もテストしないことは本当に重要ですか?もしそうなら、なぜですか? 編集:データベース、ネットワーク、Webサービスなどの外部依存関係のモックの価値を理解できます(これを明確にする動機付けをしてくれたAnna Learに感謝します)。内部依存関係、つまり他のクラス、静的関数などに言及していました。直接的な外部依存関係はありません。

12
TDDを実行する場合、プライベートメソッドを避ける必要がありますか?
私はちょうどTDDを学んでいます。パブリックメソッドはオブジェクトの整合性を検証するのに十分な情報を提供するので、プライベートメソッドはテストできず、心配するべきではないというのが私の理解です。 私はしばらくの間OOPを理解しました。私の理解では、プライベートメソッドはオブジェクトをよりカプセル化するため、変更やエラーに対する耐性が高まります。したがって、デフォルトで使用する必要があり、クライアントにとって重要なメソッドのみを公開する必要があります。 さて、プライベートメソッドのみを持ち、イベントをリッスンすることで他のオブジェクトとやり取りするオブジェクトを作成することは可能です。これは非常にカプセル化されますが、完全にはテストできません。 また、テストのためにメソッドを追加するのは悪い習慣と考えられています。 これは、TDDがカプセル化と対立することを意味しますか?適切なバランスは何ですか?私は今、私のメソッドのほとんどまたはすべてを公開したいと思っています...

11
モックオブジェクトを使用するとき、ユニットテストで依存関係の問題をどのように検出しますか?
クラスXがあり、動作X1を検証する単体テストを作成します。Xを依存関係とするクラスAもあります。 Aの単体テストを作成するとき、Xをモックします。つまり、Aの単体テスト中に、Xのモックの動作をX1に設定(仮定)します。時間が経ち、人々はあなたのシステムを使用し、変更を必要とし、Xは進化します。Xを変更して動作X2を表示します。明らかに、Xの単体テストは失敗し、それらを調整する必要があります。 しかし、Aではどうでしょうか?Aの単体テストは、Xの動作が変更されても失敗しません(Xのモックにより)。「実際の」(変更された)Xで実行すると、Aの結果が異なることを検出する方法は? 「それは単体テストの目的ではない」という線に沿った答えを期待していますが、単体テストにはどのような価値がありますか?すべてのテストに合格したときに、重大な変更が導入されていないことを本当に伝えているだけですか?そして、あるクラスの振る舞いが(喜んでまたは不本意で)変化するとき、どのようにすべての結果を(できれば自動化された方法で)検出できますか?統合テストにもっと集中すべきではないでしょうか?

9
CIサーバーで単体テストを実行する意味は何ですか?
CIサーバーで単体テストを実行するのはなぜですか? 確かに、何かがマスターにコミットされる頃には、開発者はすでにすべての単体テストを実行し、新しいコードで発生した可能性のあるエラーを修正しています。それは単体テストのポイントではありませんか?そうでなければ、彼らは壊れたコードをコミットしたばかりです。

19
TDDが機能する理由 [閉まっている]
最近、テスト駆動開発(TDD)が大きくなっています。プログラマーSEやその他の会場で、さまざまな問題の解決策として推奨されることがよくあります。なぜ機能するのだろうか。 エンジニアリングの観点から見ると、2つの理由で困惑しています。 「書き込みテスト+合格するまでリファクタリングする」アプローチは、信じられないほどアンチエンジニアリングに見えます。たとえば、土木技師が橋の建設にそのアプローチを使用したり、車の車の設計者を使用すると、非常に高いコストで橋や車の形状を変更することになり、その結果、よく考え抜かれたアーキテクチャのないパッチアップされた混乱になります。「リファクタリングまでのパス」ガイドラインは、多くの場合、アーキテクチャ設計を忘れ、テストに準拠するために必要なことをすべて実行することを義務付けられています。つまり、ユーザーではなくテストが要件を設定します。このような状況で、結果の良い「虚偽」、つまり正しいだけでなく、拡張性、堅牢性、使いやすさ、信頼性、安全性、安全性などの最終結果をどのように保証できますか?これは、アーキテクチャが通常行うことです。 テストでは、システムが機能することを保証できません。そうでないことを示すだけです。言い換えれば、テストは、テストに失敗した場合にシステムに欠陥があることを示しますが、すべてのテストに合格したシステムは、テストに失敗したシステムより安全ではありません。ここでは、テスト範囲、テスト品質、およびその他の要因が重要です。「すべてがグリーン」な結果が多くの人々にもたらす誤った安全感情は、民間および航空宇宙産業では非常に危険であると報告されています。テスト戦略として」。多くの場合、テスト戦略はチェックされません。または、誰がテストをテストしますか? 要約すると、私は「テスト」ビットよりもTDDの「ドリブン」ビットに関心があります。テストはまったく問題ありません。私が得られないのは、それを行うことで設計を推進することです。 ソフトウェアエンジニアリングのTDDが優れた実践である理由と、ソフトウェアの場合に上記で説明した問題が関連性がない(または関連性が十分でない)理由を含む回答をご覧ください。ありがとうございました。
92 testing  tdd 

12
テストがテストするコードとインラインで書かれていない理由はありますか?
最近、Literate Programmingについて少し読んで、考えさせられました...よく書かれたテスト、特にBDDスタイルの仕様は、散文よりもコードが何をするかを説明するのにより良い仕事をすることができ、大きな利点があります自身の精度を検証します。 テストするコードとインラインで記述されたテストを見たことはありません。これは、言語が同じソースファイルに記述されたときにアプリケーションとテストコードを簡単に分離する傾向がないため(そして誰も簡単にしなかったため)、または人々がテストコードをアプリケーションコードから分離するより原則的な理由があるからですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.