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

私は同僚とユニット/統合テストについて話し合っていましたが、彼はユニットテストの作成に対して興味深いケースを作りました。私は大規模なユニットテスト（主にJUnit）の支持者ですが、彼がいくつかの興味深い点を指摘したので、他の人の意見を聞くことに興味があります。 彼のポイントを要約するには： 主要なコードの変更（POJOの新しいセット、主要なアプリケーションのリファクタリングなど）が発生した場合、単体テストは修正されるのではなくコメントアウトされる傾向があります。 ユースケースをカバーする統合テストにより多くの時間を費やすことができます。これにより、より小さなスコープのテストの重要性が低くなります。 これについての考え？統合テストは少なくとも同じくらい価値があるように聞こえますが、私はまだプロユニットテストです（一貫して改善されたコードを生成しているのを見ています）。

35 unit-testing  integration-tests 

私の仕事では、バグを解決するすべての開発者は、このタイプのバグについて警告する新しいユニットテストを追加する必要があります（再び発生する場合）。単体テストが不可能な場合（たとえば、Webページのデザインの問題）、QA部門はテストケースを作成して手動でチェックする必要があります。 この背後にある考え方は、製品のリリース前に欠陥が検出されなかった場合、それを検出するための適切な単体テストがないためであるということです。そのため、開発者が追加する必要があります。 問題は、これはどのソフトウェア開発方法論でも一般的ですか？このテクニックには名前がありますか？私はそれについてもっと学びたいのですが、それから始めるにはいくつかの情報が必要です。

35 unit-testing  issue-tracking  qa 

私は最近、同じクラス内のメソッドから同じクラス内のメソッドへの結果または呼び出しをスタブするのに最適な次の2つのメソッドを友人と話していました。 これは非常に単純化された例です。実際には、機能ははるかに複雑です。 例： public class MyClass { public bool FunctionA() { return FunctionB() % 2 == 0; } protected int FunctionB() { return new Random().Next(); } } これをテストするために、2つのメソッドがあります。 方法1：関数とアクションを使用して、メソッドの機能を置き換えます。例： public class MyClass { public Func<int> FunctionB { get; set; } public MyClass() { FunctionB = FunctionBImpl; } public bool FunctionA() …

35 c#  design  unit-testing 

アプリケーションで複雑な正規表現の単体テストを作成する必要がありますか？ 一方では、入力と出力の形式は単純で明確に定義されていることが多いため、テストが容易であり、非常に複雑になることが多いため、テストは特に価値があります。 一方、それら自体は、あるユニットのインターフェースの一部ではありません。インターフェイスのみをテストし、暗黙的に正規表現をテストする方法でテストする方が良い場合があります。 編集： 私は、これが内部コンポーネントの単体テストの特殊なケースであるとコメントしているDoc Brownに同意します。 しかし、内部コンポーネントの正規表現にはいくつかの特別な特性があります。 単一行の正規表現は、実際には独立したモジュールではなく、非常に複雑になる可能性があります。 正規表現は、副作用なしで入力を出力にマップするため、個別にテストするのは非常に簡単です。

34 unit-testing  testing  regular-expressions 

この質問がしばらくの間私を悩ませていたので、この質問がいくつかの興味深い答えを与えることを願っています。 ASP.NET MVCでコントローラーを単体テストすることで実際の価値はありますか？ それが意味することは、ほとんどの場合（そして私は天才ではありません）、私のコントローラーメソッドは、そのような最も複雑なものであってもです： public ActionResult Create(MyModel model) { // start error list var errors = new List<string>(); // check model state based on data annotations if(ModelState.IsValid) { // call a service method if(this._myService.CreateNew(model, Request.UserHostAddress, ref errors)) { // all is well, data is saved, // so tell the user …

33 c#  unit-testing  asp.net-mvc 

最初に単体テストを作成してからコードの作成を開始することをお勧めします。しかし、私にとっては、逆の方がはるかに快適だと感じています-実際にコードを書いた後、より明確になったと感じているので、コードを書いてからユニットテストを書いてください。コードを作成してからテストを作成すると、テスト可能なデザインの作成に専念しても、コードを少し変更してテスト可能にする必要がある場合があります。一方、テストを作成してからコードを作成すると、コードが形成されるときにテストが頻繁に変更されます。 テストの作成を開始してからコーディングに進むための多くの推奨事項がありますが、逆にコードを作成してから単体テストを行う場合のデメリットは何ですか？

33 testing  unit-testing  code-quality  tdd 

ほとんどの単体テストのチュートリアル/例では、通常、個々のテストごとにテストするデータを定義する必要があります。これは「すべてを単独でテストする必要がある」理論の一部だと思います。 しかし、大量のDIを含む多層アプリケーションを扱う場合、各テストのセットアップに必要なコードが非常に長くかかることがわかりました。代わりに、多くのテストスキャフォールドが事前に構築された多数のテストベースクラスを構築し、継承することができます。 この一環として、実行中のアプリケーションのデータベースを表す偽のデータセットも作成していますが、通常、各「テーブル」には1行または2行しかありません。 すべてではないにしても、すべての単体テストのテストデータの大部分を事前に定義することは、受け入れられている慣行ですか？ 更新 以下のコメントから、単体テストよりも統合を進めているように感じます。 私の現在のプロジェクトはASP.NET MVCで、Entity Framework Code Firstを使用した作業単位とテスト用のMoqを使用しています。UoWとリポジトリをモックしましたが、実際のビジネスロジッククラスを使用し、コントローラーアクションをテストしています。テストでは、UoWがコミットされていることを頻繁に確認します。たとえば、次のとおりです。 [TestClass] public class SetupControllerTests : SetupControllerTestBase { [TestMethod] public void UserInvite_ExistingUser_DoesntInsertNewUser() { // Arrange var model = new Mandy.App.Models.Setup.UserInvite() { Email = userData.First().Email }; // Act setupController.UserInvite(model); // Assert mockUserSet.Verify(m => m.Add(It.IsAny<UserProfile>()), Times.Never); mockUnitOfWork.Verify(m => m.Commit(), Times.Once); } } …

33 unit-testing 

グアバには、自動生成されるユニットテストケースがあります。 グアバには膨大な数の単体テストがあります。2012年7月現在、guava-testsパッケージには286,000を超える個別のテストケースが含まれています。これらのほとんどは、手書きではなく自動的に生成されますが、特にcom.google.common.collectの場合、グアバのテスト範囲は非常に徹底しています。 それらはどのように生成されましたか？それらを設計および生成するためにどのような技術と技術が使用されましたか？

31 java  unit-testing  test-automation 

私は同僚に単体テスト（およびテスト全般）の概念を紹介したいと思います。現在、テストはまったく行われておらず、実際にUIを介してタスクを実行して目的の結果を確認することにより、テストが行​​われています。ご想像のとおり、コードは正確な実装と非常に緊密に結合されています。クラス内にあり、システム全体で再利用されるコードがメソッド間でコピーおよび貼り付けされることさえあります。 要件が変更されたため、以前に書いたモジュールを修正するように依頼されましたが、それはかなり疎結合です（希望するほど多くはありませんが、他の多くの概念を導入することなく取得できます）。修正されたコードに単体テストのスイートを含めて、期待どおりに機能することを「証明」し、テストの仕組みを実証することにしました。コードの一部はすでに記述されているため、真のTDDをフォローしていませんが、作成する必要がある新しいコードについては、TDDの概念に従うことを望んでいます。 今、どうしてコードを書くのに1日か2日以上かかるのかと聞かれるのは避けられないだろう、なぜなら私がやり取りすることの一部はすでにシステムに存在しているからだ））でコードをチェックすると、この「テスト」プロジェクトとは何かを尋ねられます。テストの基本を説明することはできますが、他の人が理解する方法で実際の利点を説明することはできません（テストは自分でアプリを実行する必要があると考えているためです。 " か否か）。彼らは疎結合の概念を理解していません（疎結合されたものは何もないという事実から明らかです。私が書いたコード以外のインターフェースすらありません）。それを利益として使用しようとすると、おそらく「ハァッ」を得るでしょう。ある種の見た目であり、既存のいくつかのモジュールを作り直さずに、おそらく「プログラミング」ではなく時間の浪費と見なされるIoCコンテナを導入することなく、やりたいほどゆるくすることはできません。 誰も私がこのコードを指す方法についての提案を持っていますか？私のものが悪いことを除いて）またはそれは時間の無駄のように見えることなく、実際の価値を追加しませんか？

30 testing  unit-testing  teamwork 

私は、一部の人々がテスト駆動開発の大規模な支持者であることを知っています。私は過去に単体テストを使用しましたが、簡単にテストできる操作、またはおそらく正しいと思われる操作をテストするためだけに使用しました。完全またはほぼ完全なコードカバレッジは、多くの時間がかかるようです。 テスト駆動開発を使用するプロジェクトは何ですか？特定のサイズを超えるプロジェクトにのみ使用しますか？ 私はそれを使用する必要がありますか？信じさせて！

30 programming-practices  unit-testing  tdd 

単体テストの期待される結果をハードコーディングする必要がありますか、それとも初期化された変数に依存できますか？ハードコードまたは計算された結果は、単体テストでエラーを導入するリスクを高めますか？私が考慮していない他の要因はありますか？ たとえば、これら2つのうち、どちらがより信頼性の高い形式ですか？ [TestMethod] public void GetPath_Hardcoded() { MyClass target = new MyClass("fields", "that later", "determine", "a folder"); string expected = "C:\\Output Folder\\fields\\that later\\determine\\a folder"; string actual = target.GetPath(); Assert.AreEqual(expected, actual, "GetPath should return a full directory path based on its fields."); } [TestMethod] public void GetPath_Softcoded() { MyClass target = …

29 c#  unit-testing 

近年、私は大規模なプロジェクトや小さなツールの人々のために小さなコンポーネントのみを作成しました。私はユニットテストを書いたことがなく、常にそれらの書き方を学び、実際にユニットテストを作成するのは、単にプログラムを起動して実際にテストするよりもはるかに時間がかかります。 私はちょうど完了するのに数か月かかる可能性があるかなり大規模なプロジェクトを開始しようとしていますが、（いつものように）書いているときに要素をテストしようとしていますが、ユニットテストで時間を節約できるかどうか疑問に思っています。 誰かが良いアドバイスをすることができるかどうか疑問に思っていました： プロジェクトの開始時に単体テストを検討し、TDDアプローチを採用する可能性があります。 各セクションが完了した後、テストを書くだけです。 プロジェクトを完了し、最後に単体テストを作成する必要があります。

29 testing  unit-testing 

TDDと単体テストは、現時点では大きな絶賛のようです。しかし、他の形式の自動化されたテストと比べて本当に便利なのでしょうか？ 直感的には、自動化された統合テストは単体テストよりもはるかに便利だと思います。私の経験では、ほとんどのバグはモジュール間の相互作用にあるようで、各ユニットの実際の（通常は制限された）ロジックではありません。また、モジュール間のインターフェイスの変更（および変更された事前条件と事後条件）のために、しばしば回帰が起こりました。 私は何かを誤解していますか、またはなぜ統合テストに比べて単体テストがそれほど重視されているのですか？それは単に統合テストがあなたが持っているものであり、ユニットテストが開発者として適用するために学ぶ必要がある次のものであると仮定されているからです。 それとも、単体テストは、自動化の複雑さに比べて単純に最高の利益をもたらすでしょうか？ 自動化された単体テスト、自動化された統合テスト、および自動化された受け入れテストでどのような経験がありますか？なぜ？ 次のプロジェクトで自動化するために、テストの形式を1つだけ選択する必要がある場合、それはどのようになりますか？ 前もって感謝します。

29 testing  unit-testing  automation  acceptance-testing 

私はソフトウェア開発と単体テストの作成について考えていました。私は次のアイデアを得ました： 開発者のペアがあるとしましょう。各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目は機能の単体テストを記述します。テストはコードの後に​​記述されます。私の考えでは、彼らはお互いを助けますが、かなり別々に働きます。理想的には、2つの同様のサイズの機能で動作し、テスト準備のために交換します。 このアイデアにはいくつかの利点があると思います。 テストは、実装の詳細を確認できる誰かが作成します。 ペアプログラミング（2つの機能を同時に使用）よりも作業を少し速くする必要があります。 テストとコードの両方に責任者がいます。 コードは少なくとも2人でテストされ、 コードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書いてコーナーを避ける特別な動機付けになるでしょう。 また、コード開発とテスト開発の間にコードレビューのために別の開発者を追加することも良い考えです。 このアイデアの欠点は何ですか？それはすでに私にとって未知の方法論として説明されており、ソフトウェア開発で使用されていますか？ PS。私はプロのプロジェクトマネージャーではありませんが、プロジェクト開発プロセスについては何かを知っており、いくつかの最も一般的な方法論を知っています。

28 unit-testing  methodology 

TDDを使用して開発する予定の新しい（非常に大きな）プロジェクトが開始されました。 TDDのアイデアは失敗しました（多くのビジネス上の理由とビジネス以外の理由）が、今は会話があります-いずれにしてもユニットテストを書くべきかどうか。私の友人は、TDDを使用せずに単体テストを書くことには意味がない（またはゼロに近い）ため、統合テストのみに焦点を合わせる必要があると言います。単純な単体テストを記述することには、コードの将来性をより高めるために、まだある程度の意味があると私は反対に思います。どう思いますか？ 追加：これは>> this question <<の複製ではないと思います-UTとTDDの違いを理解しています。私の質問は違いではなく、TDDなしで単体テストを書く感覚です。

28 unit-testing  tdd