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

最近、アプリケーションでロケール固有の問題を発見しましたが、修正は簡単でしたが（何が起こっているのかがわかった後）、この点で単体テストの実践について考えているチームが見つかりました。 これらの問題をできるだけ早く、理想的には顧客が発見する前にキャッチし、将来ロケール固有のバグを再導入しないように保護したいと考えていますが、少なくとも1つの他の文化ですべてのユニットテストを複製することは多くのようですオーバーヘッド。 どのように、またはどのようにマルチロケール単体テストにアプローチしますか？

17 unit-testing  localization 

これらは、TDDに関するRobert C. Martinの規則です。 失敗した単体テストに合格しない限り、実稼働コードを作成することはできません。 失敗するのに十分な数以上の単体テストを作成することはできません。コンパイルの失敗は失敗です。 1つの単体テストに合格するのに十分な量を超える量産コードを記述することはできません。 価値があると思われるが、本番コードを変更せずに合格するテストを作成する場合： それは何か間違ったことをしたということですか？ 役立つ場合は、将来そのようなテストを書くことを避けるべきですか？ そのテストをそこに残すか、削除する必要がありますか？ 注： 私はここでこの質問をしようとしていました：ユニットテストに合格することから始められますか？ しかし、私は今まで十分に質問を明確にすることができませんでした。

17 testing  unit-testing  tdd 

プロジェクトの単体テストと統合テストを作成する必要があります。 すべてのテストを単一のテストフォルダーに入れる必要がありますか？ または、単体テストと統合テストをそれぞれ個別のテストフォルダーに配置する必要がありますか？ それとも、それらを別々のプロジェクトに入れるべきですか？ それらをまとめると、このアプローチには利点や欠点がありますか？

17 architecture  unit-testing  integration-tests 

最初に、タイトルをおaびします。それを説明する最も簡単な方法は考えられませんでした！ ユニットテストを書きたいメソッドがあります。メソッドの実装については説明せず、テストのみを行いたいので、かなり汎用的にしておきます。メソッドは次のとおりです。 public void HandleItem(item a) { CreateNewItem(); UpdateStatusOnPreviousItem(); SetNextRunDate(); } そのため、このクラスにはパブリックメソッドが1つあり、このメソッドがプライベートメソッドを呼び出してロジックを実行します。 それで、ユニットテストを書くとき、私は3つすべてが行われたことをチェックしたいです。それらはすべて同じ実行で呼び出されるため、1つのテストとして実行できると考えました。 public void GivenItem_WhenRun_Thenxxxxx { HandleItem(item); // Assert item has been created // Assert status has been set on the previous item // Assert run date has been set } しかし、3つの別々のテストとして書くこともできると考えました。 public void GivenItem_WhenRun_ThenItemIsCreated() { HandleItem(item); } public …

16 c#  unit-testing 

唯一の実際のロジックは、外部APIのクエリ構文にあります。APIを照会するかどうかをテストするのではなく、正しいデータが返されるような方法で照会することをテストする必要があります。たとえば、いくつかの擬似コード： function retrieve_related_data(id) { query = "[potentially long, syntactically complex query that uses param id to get some data]"; results = api_wrapper.query(query); return results; } 構成されたAPIを使用したより具体的な例： function retrieveLifeSupportingObjectsWithinRegion(id) { query = " within region(" + id + ") as r find objects matching hydration>0 and temp_range has 75 send name, …

16 unit-testing  testing  integration-tests 

2012年 のこの質問の著者と2013 年のこの質問の著者のように、アプリケーションを適切にテストするためにラップする必要があるサードパーティのライブラリがあります。一番上の答えの状態： 常にインターフェイスの背後にサードパーティのタイプとメソッドをラップする必要があります。これは退屈で痛みを伴う場合があります。コードジェネレータを記述したり、ツールを使用してこれを行うことができます。 私の場合、ライブラリはオブジェクトモデル用であり、その結果、この戦略を成功させるためにラップする必要があるクラスとメソッドの数が多くなります。単に「退屈で痛みを伴う」だけでなく、これはテストの難しい障壁になります。 この質問から4年間で、分離フレームワークが大きく進歩したことを認識しています。私の質問は、サードパーティのライブラリを完全にラップする効果を達成するためのより簡単な方法が今あるのでしょうか？このプロセスの痛みを取り除き、手作業の労力を減らすにはどうすればよいですか？ 私の質問はラッピングの手間を減らすことに関するものなので、私の質問は最初にリンクした質問の複製ではありません。これらの他の質問は、ラッピングが理にかなっているかどうかを尋ねるだけであり、どのように労力を小さく保つことができるかではありません。

16 unit-testing  third-party-libraries  wrapper 

GUIアプリのUIユニットテストを作成してみましたが、最初に作成したときにはうまく機能しますが、設計が変更されるたびに（つまり、非常に頻繁に）壊れるという問題に直面しています。GUIの保守可能な単体テストを作成するためのガイドラインを見つけるのに苦労しています。 今のところ、私が発見したことの1つは、「このコンポーネントは入力データをどこかに表示する必要がある」というテストが適切であることです（HTMLでは非常に簡単です）。通常、コンポーネントの特定の部分の特定の状態を確認するテストは脆弱です。クリック-クリック-クリック-期待のようなテストは、ユーザーの行動と基礎となるビジネスロジック（最も重要な部分）を追跡しようとするため、通常は脆弱です。良いテストを書くにはどうすればいいですか？ もっと正確に言うと、UIで何をテストできるかについて、正確なテスト方法ではなく、いくつかのパターンを知りたいです。命名規則と固定識別子は優れていますが、コアの問題、つまりGUIが大きく変わるという問題は解決しません。変化する可能性が最も低い動作をテストしたいと思います。テストする正しいものを見つける方法は？

16 unit-testing  language-agnostic  user-interface  maintainability 

私はTDDを宗教的に守ります。私のプロジェクトは通常、テストカバレッジが85％以上であり、意味のあるテストケースがあります。 私はHBaseで多くの作業を行っていますが、メインのクライアントインターフェイスであるHTableはモックの苦痛です。ライブエンドポイントを使用するテストを記述するよりも、ユニットテストを記述するのに3〜4倍時間がかかります。 哲学的に、モックを使用するテストは、ライブエンドポイントを使用するテストよりも優先されるべきであることを知っています。しかし、HTableのモックは深刻な痛みであり、実際のHBaseインスタンスに対するテストよりも多くの利点があるとは確信していません。 私のチームの全員がワークステーションでシングルノードHBaseインスタンスを実行し、JenkinsボックスでシングルノードHBaseインスタンスを実行しているため、可用性の問題はありません。ライブエンドポイントテストは、モックを使用するテストよりも明らかに実行に時間がかかりますが、実際には気にしません。 現在、すべてのクラスに対してライブエンドポイントテストと模擬ベースのテストを作成しています。モックを捨てたいのですが、結果として品質が低下するのは望ましくありません。 皆さんはどう思いますか？

16 unit-testing  tdd  integration-tests  mocking 

ユニットテストを行うとき、どのくらいの量のデータをフィードし、テスト対象のユニットから戻ってくるのかを議論することがよくあるので、実際のテストファイルに含める必要があります。 私が常に苦労しているトレードオフは： テストの大部分（コードボリューム内）が入力データと出力データで構成されている場合、実際にテストを読み取ることは困難に思えますが、実際の入出力を簡単に確認できます。 ファイルからテストデータを読み込むと、可能なデータ入力のバリエーションを簡単にテストでき、テストデータを複数のテストに簡単に再利用できますが、入力が正確に何であるかを確認するには、ソースコードを残しておく必要があります。 これらのいずれかがアンチパターンですか？

16 unit-testing  anti-patterns  unit-test-data 

ユニットテストは初めてで、DBを呼び出してDTOを設定するREST Webメソッドが1つあります。擬似コードは public object GetCustomer(int id) { CustomerDTO objCust = //get from DB return objCust; } 私の疑問は、含まれるこれらのメソッドとテストのタイプ（Integration / Unit）のテストの書き方です。単体テストの場合、DBにアクセスする必要がありますか。そうであり、顧客IDを渡してアサーションをほとんど行わない場合、データが最終的に変更されて失敗する可能性があります。 ここでこれらの概念を理解している何かが欠けていると思います。

16 testing  unit-testing  rest  integration-tests 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 どのようなソフトウェアテストを知っていますか？テスト駆動開発、単体テストなどについて聞いたことがありますが、それらの重要性と違いを理解できません。たとえば、なぜ回帰テストや受け入れテストを使用するのでしょうか。彼らが提供する利点は何ですか？

16 unit-testing  testing  tdd  integration-tests  acceptance-testing 

大規模なASP.NET Webフォームアプリケーションの既存のコードベースのクリーンアップを開始する方法に関する戦略を学習することを目的として、「レガシーコードとクリーンコードの効果的な使用」を読んでいます。 このシステムは2005年から使用されており、それ以来多くの機能強化が行われています。もともと、コードは次のように構成されていました（そして、まだ大部分はこのように構成されています）： ASP.NET（aspx / ascx） コードビハインド（c＃） ビジネスロジックレイヤー（c＃） データアクセス層（c＃） データベース（Oracle） 主な問題は、コードがオブジェクト指向のように手続き的に偽装されていることです。これは、両方の本で説明されているすべてのガイドラインに事実上違反しています。 これは、ビジネスロジックレイヤーの典型的なクラスの例です。 public class AddressBO { public TransferObject GetAddress(string addressID) { if (StringUtils.IsNull(addressID)) { throw new ValidationException("Address ID must be entered"); } AddressDAO addressDAO = new AddressDAO(); return addressDAO.GetAddress(addressID); } public TransferObject Insert(TransferObject addressDetails) { if (StringUtils.IsNull(addressDetails.GetString("EVENT_ID")) || StringUtils.IsNull(addressDetails.GetString("LOCALITY")) || …

16 c#  .net  unit-testing  object-oriented 

データベースを操作しながら、ユニットのテストを可能にするOOP戦略にはどのようなものがありますか？Userクラスがあり、本番環境がMySQLに対して機能しているとします。PHPを使用してここに示す2つの可能なアプローチがあります。 load()およびのインターフェイスで$ data_sourceを渡し、save()データのバックエンドソースを抽象化します。テスト時には、別のデータストアを渡します。 $ user = new User（$ mysql_data_source）; $ user-> load（ 'bob'）; $ user-> setNickname（ 'Robby'）; $ user-> save（）; データベースにアクセスし、結果行をユーザーのコンストラクターに渡すファクトリーを使用します。テスト時には、$ rowパラメーターを手動で生成するか、UserFactory :: $ data_sourceでオブジェクトをモックします。（変更をレコードに保存するにはどうすればよいですか？） class UserFactory { static $data_source; public static function fetch( $username ) { $row = self::$data_source->get( [params] ); $user = new User( $row ); return $user; …

16 architecture  unit-testing  object-oriented  database 

興味深いことに、メディアがどこにあるかを見るために、この質問をそこに投げ出したいと思います。 過去12か月で、TDDとソフトウェア開発におけるアジャイルの価値の多くを取り上げました。私はソフトウェアの開発がどれほど良くなったかに圧倒され、それらを原則から外すことはありませんでした。まで...私は年間の持ち帰り給与を倍増する契約の役割を提供されました。 私が参加した会社は特定の方法論を踏んでおらず、チームはコードの匂いやソリッドなどのことを聞いていませんでしたし、チームでさえもしていないなら、TDDに時間を費やすことはありませんでした実際にユニットテストを見ました。売り切れですか？いいえ、完全ではありません...コードは常に「ボブおじさんの教えに従って」「きれいに」書かれ、SOLIDの原則は必要に応じて私が書くコードに常に適用されます。しかし、テストフレームワークを作成したとしても、テストフレームワークを正しく使用/保守することはありませんでした。 それを例にとると、開発者は個人的にお金/その他の利益のために職人技の原則を落とすべきではないという点を教えてください。これは、自分のニーズ、ビジネスニーズ、職人技などのためにどれだけ関心があるかについて、非常に個人的な意見になり得ることを理解しています。しかし、たとえば、テストチームは、プログラミングの単体テストを理解するのではなく、私がやったように自分自身を許すことができるでしょうか？あなたが落とすものがあることを考えると、通常はあなたが落とすものを補うビジネスに等しい費用があるはずです-できれば、もちろんあなたがあなた自身のポケットを並べてコミュニティ/社会的コラボレーションではなく）。 お金を2倍にして、RADに戻りますか？または、歩いて、アジャイルをしている人を探して、決して振り返らないでください...

16 agile  testing  unit-testing  tdd  sdlc 

値のみの列挙型（Javaで実行できるメソッドはない）があり、この列挙型がシステムのビジネス定義の一部である場合、単体テストを作成する必要がありますか？ 単純で冗長に見えるかもしれませんが、ユニット/統合/ ui / etcに関係なく、ビジネス仕様に関係するものをテストで明示的に作成する必要があると思います。テストするか、テスト方法として言語の型システムを使用します。列挙型（Javaなど）に必要な値は、ビジネスの観点から、型システムを使用してテストできないため、そのための単体テストが必要だと思います。 この質問は類似していない、この1、それは私と同じ問題に対処していないので。その質問にはビジネス機能（savePeople）があり、その人は内部実装（forEach）について問い合わせています。そこには、言語コンストラクト（forEach）をカプセル化する中間ビジネスレイヤー（人を救う機能）があります。ここで、言語構造（enum）は、ビジネスの観点から動作を指定するために使用されるものです。 この場合、実装の詳細は、データの「真の性質」、つまり値のセット（数学的な意味で）と一致します。ほぼ間違いなく不変のセットを使用できますが、同じ値がまだ存在しているはずです。配列を使用する場合は、ビジネスロジックをテストするために同じことを行う必要があります。ここでの難問は、言語構成がデータの性質と非常によく一致するという事実であると思います。自分自身を正しく説明したかどうかわかりません

15 unit-testing  testing  type-systems  enum