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

私はユニットテストで把握しようとしています。 デフォルトの辺の数が6に等しい（ただし、4、5辺など）ことができるダイがあるとします。 import random class Die(): def __init__(self, sides=6): self._sides = sides def roll(self): return random.randint(1, self._sides) 以下は有効/有用な単体テストでしょうか？ 6面ダイスの1〜6の範囲でロールをテストします 6面ダイスの0のロールをテストします 6面ダイスの7のロールをテストします 3面ダイスの1〜3の範囲でロールをテストします。 3面ダイスの0のロールをテストします 3面ダイスの4のロールをテストします ランダムモジュールが長い間存在していたので、これらは時間の無駄だと思っていますが、ランダムモジュールが更新された場合（たとえば、Pythonバージョンを更新した場合）、少なくともカバーされます。 また、ダイロールの​​他のバリエーション（この場合は3など）をテストする必要もありますか、それとも別の初期化されたダイの状態をカバーするのが良いでしょうか？

18 python  unit-testing  tdd 

私たちは、長年にわたってメインプログラムのためにかなりの数の単体テストを構築してきました。数千。問題は、非常に多くのテストがあるため、どのテストがあるのか​​明確に把握していないことです。そして、それは問題です。なぜなら、どこでテストが苦手なのか（または重複箇所があるのか​​）わからないからです。 私たちのアプリはレポートエンジンです。したがって、解析のテスト（すべてのテーブルプロパティを読み取るか）、データのマージ（マージで正しいテーブルプロパティを維持したかどうか）、最終ページのフォーマット（ページがテーブルに正しく配置されているか）に使用するテンプレートを使用できます）および/または出力形式（作成されたDOCXファイルは正しいですか）。 これにテストする必要があるものを追加します。テーブルセルの周りの余白を取ります（レポートデザインにはWord、Excel、およびPowerPointを使用します）。セル内のテーブル、垂直方向に結合したセル、水平方向に結合したセル、内部テーブルに垂直方向と水平方向に結合したセルを含むテーブルを含む垂直方向と水平方向に結合したセルについて、改ページ全体のパディングをテストする必要がありますページを分割します。 それでは、そのテストはどのカテゴリに属しますか？テーブルのパディング、改ページ、ネストされたセル、垂直に結合されたセル、水平に結合されたセル、または他の何か？ そして、これらのカテゴリをどのように文書化し、単体テストに名前を付けるなどしますか？ 更新：多くの人が、カバレッジツールを使用して、完全にカバレッジがあることを確認することを提案しています。残念なことに、バグは特定の組み合わせに起因する傾向があるため、このケースでは使用が制限されています。そのため、すべてのコードはテスト済みですが、その組み合わせではありません。 たとえば、昨日、テンプレート（Word文書）のforEachループの終わりにWordブックマークを開始し、次のforEachループの始めに終了した顧客がいました。これはすべて単体テストのあるコードを使用していましたが、ブックマークを展開するテンプレートの組み合わせが25回開始され、10回終了することを考えていませんでした（2つのforEachループの行数が異なりました）。

18 unit-testing  project-structure 

医療ソフトウェアのケースに基づいたTDDトレーニング中に、「ユーザーが[保存]ボタンを押すと、システムは患者を追加し、デバイスを追加し、デバイスデータレコードを追加する」というストーリーを実装します。 最終的な実装は次のようになります。 if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed) { AddPatient(); AddDevice(); AddDeviceDataRecords(); } それを実装する方法は2つあります。 それぞれが1つのメソッド（AddPatient、AddDevice、AddDeviceDataRecords）を検証した3つのテストが呼び出されました 3つのメソッドすべてを検証する1つのテストが呼び出されました 最初のケースでは、if句の条件に何か問題が発生した場合、3つのテストすべてが失敗します。しかし、テストが失敗した場合の2番目のケースでは、何が正確に間違っているのかわかりません。どのような方法を好むでしょうか。

18 unit-testing  tdd 

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

18 testing  unit-testing  exceptions 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ユニットテストを勉強してコードに適用することを計画していましたが、同僚と話した後、一部の人はそれは必要ではなく、ほとんど利益がないと私に提案しました。また、実稼働ソフトウェアを使用して単体テストを実際に行っている企業はごくわずかであると主張しています。 私は、人々が職場で単体テストをどのように適用し、それらを使用することで得られるメリット、たとえば、コード品質の向上、長期的な開発時間の短縮などに興味があります。

18 unit-testing 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4ヶ月前に閉店。 ユニットテストをずっと愛してきたなら、あなたにとって良いことです！しかし、それが好きで生まれていない不幸な人たちのために、どうやってこの仕事をもっと楽しくすることができましたか？ これは「単体テストの正しい方法」の質問ではありません。私は、単体テストを書くことの退屈さ（あえて言う）を減らす、ちょっとした個人的なトリックを知りたいだけです。

18 productivity  unit-testing 

「確かにわかるのに、なぜあなたのテストは良いと思うのですか？Jesterは私のテストが気密であると言うこともありますが、見つかった変更が突然発生することもあります。強くお勧めします。」-ケントベック しかし、stackoverflowには「Jester」というタグすらありません。では、Jesterの最新の代替品はありますか？CoberturaやCloverなどのツールのコードカバレッジから統計を見つけること以外に、記述された単体テストが堅実であることをどのように確認できますか？

18 java  unit-testing  code-quality  tdd 

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

17 c++  unit-testing  testing 

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

17 unit-testing  testing  tdd  bdd  acceptance-testing 

私はBDDを理解しようとしています。いくつかの記事を読みましたが、理解したように、BDDはTDDの「次のステップ」です。私は両方とも非常に似ていると思うので、この記事で読むことができるように、TDDからの改良としてBDDが生まれたと言います。素晴らしい、私はアイデアが本当に好きです。 考えられない実用的なポイントが1つあります。BAがシステムが持つすべての予想される動作を書き込む.featureファイルがあります。BAとして、彼はシステムがどのように構築されているのかわからないので、次のように書きます。 +シナリオ1：アカウントにクレジットがあります+ アカウントにクレジットがあることを考えると そして、カードは有効です そして、ディスペンサーには現金が含まれています 顧客が現金を要求するとき 次に、口座から引き落とされていることを確認し、現金が支払われていることを確認します そして、カードが返されることを確認してください わかりました、これは素晴らしいことですが、システムの多くの部分が連携してそれを実現します（Account obj、Dispenser obj、Customer objなどを考えてください）。私にはこれは統合テストのように見えます。 ユニットテストが欲しいです。ディスペンサーにお金があるかどうかを確認するコードをテストするにはどうすればよいですか？または、現金が分配されますか？または、必要なときに口座から引き落とされますか？ ユニットテストと「BA Created」テストを混在させるにはどうすればよいですか？

17 unit-testing  bdd 

クライアントからの非常に特定の要件ごとに、検索結果の順序付けられていないリストのソートを支援するために、リストコンパレータに取り組んでいます。要件では、重要度の順に次のルールを使用してランク付けされた関連性アルゴリズムが必要です。 名前の完全一致 検索クエリのすべての単語の名前または結果の同義語 検索クエリの一部の単語の名前または結果の同義語（％降順） 説明内の検索クエリのすべての単語 説明内の検索クエリの一部の単語（％降順） 最終更新日が降順 このコンパレータの自然なデザインの選択は、2の累乗に基づいてスコア付けされたランキングであるように思われました。重要度の低いルールの合計は、重要度の高いルールの肯定的な一致を超えることはありません。これは、次のスコアによって達成されます。 32 16 8（降順％に基づく2次タイブレーカースコア） 4 2（降順％に基づく2次タイブレーカースコア） 1 TDDの精神で、私は最初にユニットテストから始めることにしました。一意のシナリオごとにテストケースを作成することは、ルール3および5のセカンダリタイブレーカーロジックの追加のテストケースを考慮せずに、少なくとも63の一意のテストケースになります。これは耐えがたいようです。 ただし、実際のテストは実際には少なくなります。実際のルール自体に基づいて、特定のルールにより、下位のルールが常に真になることが保証されます（たとえば、「すべての検索クエリワードが説明に表示される」場合、ルール「一部の検索クエリワードが説明に表示される」は常に真になります）。それでも、これらの各テストケースを書き出す努力のレベルは価値がありますか？これは、TDDで100％のテストカバレッジについて話すときに通常要求されるテストのレベルですか？そうでない場合、許容可能な代替テスト戦略は何でしょうか？

17 algorithms  unit-testing  tdd 

私は、キャッシュからオブジェクトとオブジェクトのリストを（フィルターを使用して）保存および取得するビジネスロジックメソッドをいくつか持っています。 検討する IList<TObject> AllFromCache() { ... } TObject FetchById(guid id) { ... } IList<TObject> FilterByPropertry(int property) { ... } Fetch..そして、Filter..呼んでAllFromCache、それがない場合、キャッシュとリターンを移入し、ちょうどそれがある場合、そこから返していました。 私は通常、これらの単体テストを避けます。このタイプの構造に対する単体テストのベストプラクティスは何ですか？ TestInitializeでキャッシュにデータを追加し、TestCleanupでキャッシュを削除することを検討しましたが、それは私には適切ではないと感じました（そうかもしれません）。

17 unit-testing  caching 

C ++でOpenGLの上にゲームとそれに付随するグラフィックエンジンを書いています。また、優れたコーディングプロセスと自動テストのファンでもあります。出力は多くの場合視覚のみであるか、非常に視覚指向であるため、グラフィックスコード+テストは非常に混同しにくいようです。 たとえば、画面にバイト単位でレンダリングされる生の画像ストリームを分析することを想像してください-比較するテストデータが必要で、作成/取得が難しく、レンダリングされた画像はしばしば同じではありません異なる時間に実行する場合のバイトレベル-アルゴリズムの小さな変更は、このアプローチを完全に破壊します。 視覚的な単体テストスイートを作成することを考えています。基本的に、さまざまなテストシーンをレンダリングし、シャドウマッピング、アニメーションなどのようなものを表示できます。CIの一部として、これらのシーンはビデオにレンダリングされます異なるメトリックのファイル（または実行可能ファイルとして残すこともできます）。ビデオファイルの手動検査が必要になりますが、少なくともある程度自動化および標準化されます。 どう思いますか？もっと良い方法がありますか？

17 c++  unit-testing  graphics  opengl  test-automation 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 テスト駆動開発を使用して開発されたオープンソースアプリケーションは、単体テストがどのように機能するかのモデルとして機能しますか？ C＃と.NETの例をご覧ください。（ライブラリだけでなく、アプリケーションについても言及していることに注意してください。） 私は、TDDを信じて実践したい中間層のプログラマーです。私が日々の仕事で取り組んでいるアプリはかなり複雑です（約100万行のコード）。さらに単体テストを導入したいと思います。いくつかの単体テストが用意されていますが、TDDでの努力と、既にテスト中のコードの作業は励みになりませんでした。 私の認められた限られた経験では、TDDはデカップリングの名前の多くの複雑さを奨励するようです。テストするのが難しく、偶然にもクリティカルになる傾向があるアプリの一部は、周辺にプッシュされ、統合テストの領域に書き込まれます。（私はここでの通常の容疑者、ファイルシステムへのアクセス、データベースからのオブジェクトのハイドレーション、非同期ウェブコールなどを考えています） テスト中のコードには、オブジェクト間の多くのコラボレーションが含まれる傾向があり、おそらくいくつかの単純なフローロジックはすべてメモリ内で発生し、すべてを完全に分離する必要がなければ、おそらくよりシンプルで理解しやすい方法で記述できます検査用の。 私は依存関係などをモックするテクニックを理解していますが、私の経験では、モックを多用すると非常に脆弱なテストになります。一連のテストが赤くなるのを見て最初の本能が「すごい、今はすべてのモックを修正しなければならない」という場合、テストはセーフティネットではなくドラッグになっています。 私はこの精神的な障壁を乗り越えようとしていますが、その一環として、マイケルフェザーズの著書「Working Effectively with Legacy Code」を読んでいます。不足しているものの一部を見せてくれることを願っています。 また、コードカバレッジが良好な自明ではない.NETアプリケーション（コンテンツ管理システム、CRUDアプリなど）を調べたいと思います。ボブおじさんが語るFitNesseテストフレームワークは、おそらく検討するものですが、私が最もよく知っている言語で書かれたものを見るといいでしょう。 提案や知恵の言葉は大歓迎です。

17 unit-testing  tdd 

背景：私が取り組んでいるモジュール用にいくつかを作成することで、同僚に単体テストの概念を導入しようと考えています。要件が最近変更され、さらに抽象化/相互作用が必要になったため、アプリケーションを手動で確認することなく機能することを「証明」する一連のテストを開発するのに適した方法のようです。 ただし、問題は、モジュールがPDFやXSLなどのモックできない外部要因に依存していることです。基本的に、データベースからXMLを読み取り、XSL変換を適用してから、ABCPDFと呼ばれるライブラリを使用してPDFに変換します。このPDFは、静的テンプレートに基づいて別のPDFとマージされます。XMLをテストし、値が正しいことを確認できることはわかっていますが、潜在的なバグや問題の多くは、完成したドキュメントの実際の表示に関連しています。たとえば、テキスト文字列が折り返される時間や、特定のHTMLエリア文書等、との関係にあり、その名前を私は[ない受け入れテスト、他の種類]、およびない忘れテストの第三種...（私はこれらはおそらく統合テストやある実現これらのものをテストすることも可能ですユニットは、 テスト）私の知る限り、PDFを作成してから読み返すか、HTML文字列（つまり、変換されたXML）を作成して手作業で解析し、特定のテーブルセルの存在を確認するまで、他のテーブルセルとの関係。 このような状況では、情報が正しいことを確認するために単体テストに焦点を当て、PDF を作成するか、それらをマージするか、実際の表示の問題を手動でテストする必要がありますか？

17 unit-testing