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

私は最近、多くのDebug.Assert（C＃）が散在するいくつかの新しく書かれたコードに出会いました。 一般にTDD、BDD、および単体テストを使用しているにもかかわらず、これを広く使用する必要がありますか？

23 unit-testing  assertions 

私は自分自身をDDDの専門家とは考えていませんが、ソリューションアーキテクトとして、可能な限りベストプラクティスを適用しようとしています。私は、DDDのノー（パブリック）セッター「スタイル」の賛否両論について多くの議論があることを知っており、議論の両側を見ることができます。私の問題は、スキル、知識、経験が非常に多様なチームで働いているということです。つまり、すべての開発者が「正しい」方法で作業することを信頼することはできません。たとえば、オブジェクトの内部状態の変更がメソッドによって実行されるがパブリックプロパティセッターを提供するようにドメインオブジェクトが設計されている場合、誰かがメソッドを呼び出す代わりにプロパティを設定することは避けられません。この例を使用します。 public class MyClass { public Boolean IsPublished { get { return PublishDate != null; } } public DateTime? PublishDate { get; set; } public void Publish() { if (IsPublished) throw new InvalidOperationException("Already published."); PublishDate = DateTime.Today; Raise(new PublishedEvent()); } } 私の解決策は、プロパティセッターをプライベートにすることです。これは、オブジェクトをハイドレートするために使用しているORMがリフレクションを使用してプライベートセッターにアクセスできるためです。ただし、単体テストを作成しようとすると問題が発生します。たとえば、再発行できないという要件を検証する単体テストを作成する場合、オブジェクトが既に発行されていることを示す必要があります。確かに2回Publishを呼び出すことでこれを行うことができますが、私のテストでは、最初の呼び出しでPublishが正しく実装されていると想定しています。それは少し臭いようです。 次のコードを使用して、シナリオをもう少し現実的にしましょう。 public class Document { public Document(String title) …

23 unit-testing  domain-driven-design 

単体テストを作成するとき、コードの品質と可読性を高めるために余分な時間を費やす価値はありますか？ テストを書くとき、より速く書くために、そして非常に多くの変数の使用を避けるために、私はしばしばDemeterの法則を破ります。技術的には、単体テストは直接再利用されません-それらはコードに厳密にバインドされているため、それらに多くの時間を費やす理由は見当たりません。機能する必要があるだけです。

23 unit-testing  code-quality 

私はコードをより堅牢にしようとしており、ユニットテストについて読んでいますが、実際の有用な使用法を見つけることは非常に困難です。たとえば、ウィキペディアの例： public class TestAdder { public void testSum() { Adder adder = new AdderImpl(); assert(adder.add(1, 1) == 2); assert(adder.add(1, 2) == 3); assert(adder.add(2, 2) == 4); assert(adder.add(0, 0) == 0); assert(adder.add(-1, -2) == -3); assert(adder.add(-1, 1) == 0); assert(adder.add(1234, 988) == 2222); } } 必要な結果を手動で計算してテストする必要があるため、このテストはまったく役に立たないと感じています。ここでのより良い単体テストは assert(adder.add(a, b) == (a+b)); ただし、これはテストで関数自体をコーディングするだけです。誰かがユニットテストが実際に役立つ例を教えてもらえますか？参考までに、私は主に〜10のブール値といくつかのintを受け取り、これに基づいてintの結果を与える「プロシージャ」関数を主にコーディングしています。テスト。編集：また、これは（おそらく設計が不適切な）ルビーコード（私が作成しなかった）を移植しているときに正確にすべきでした

23 unit-testing 

現在、ASP.Net MVCアプリケーションの基礎を設定しています。どのような単体テストを作成する必要があるのか​​を検討しています。私は複数の場所で人々が本質的に「あなたの意見をテストすることを気にしないでください、ロジックはなく、簡単で、統合テストでカバーされます」と言ってきました。 これがどのように受け入れられた知恵になったのか理解できません。統合テストは、単体テストとはまったく異なる目的を果たします。何かが壊れた場合、統合テストが壊れた30分後に知りたくないので、すぐに知りたいです。 サンプルシナリオ： Customerエンティティを持つ標準のCRUDアプリを扱っているとしましょう。顧客には名前と住所があります。テストの各レベルで、顧客の取得ロジックが名前と住所の両方を適切に取得することを確認します。 リポジトリを単体テストするために、データベースにアクセスする統合テストを作成します。ビジネスルールを単体テストするために、リポジトリをモックアウトし、ビジネスルールに適切なデータをフィードし、期待される結果が返されることを確認します。 やりたいこと： UIの単体テストを行うには、ビジネスルールをモックアウトし、予想される顧客インスタンスをセットアップし、ビューをレンダリングし、指定したインスタンスの適切な値がビューに含まれていることを確認します。 立ち往生していること： リポジトリの単体テストを行うには、統合テストを作成し、適切なログインを設定し、データベースに必要なデータを作成し、ブラウザーを開いて顧客に移動し、結果のページに適切なものが含まれていることを確認します指定したインスタンスの値。 上記の2つのシナリオにはオーバーラップがありますが、テストのセットアップと実行に必要な時間と労力の主な違いは理解しています。 私（または別の開発者）がアドレスフィールドをビューから削除した場合、統合テストがこれを検出するのを待ちたくありません。私が欲しいのは、毎日複数回行われるユニットテストで発見され、フラグが立てられます。 重要な概念を把握していないように感じます。MVCビューの有効性に関するテストのフィードバックをすぐに望むのはなぜ悪いのか、誰かが説明できますか？（または、悪くない場合は、フィードバックを得るための予想される方法ではありません）

23 unit-testing  asp.net-mvc 

ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私は過去4年半にわたってエンタープライズの分野で働いてきましたが、一般的に言って、エンタープライズはテストファーストスタイルの開発を促進する環境ではないことに気付きました。プロジェクトは通常、固定コスト、固定タイムライン、およびウォーターフォールスタイルです。ユニットテストが行​​われたとしても、通常はQAフェーズでの開発後に別のチームによって行われます。 企業で働く前に、私は多くの中小企業に相談しましたが、テストファーストスタイルの開発プロジェクトにお金を払うつもりはありませんでした。彼らは通常、開発をすぐに開始するか、短い設計期間の後、つまりアジャイルに似たものを望んでいましたが、一部のクライアントはすべてがウォーターフォールのようにマッピングされることを望みました。 テスト駆動開発は、どのタイプのショップ、企業、クライアントで最も効果的ですか？どのタイプのプロジェクトがTDDを助長する傾向がありますか？

23 testing  agile  unit-testing  tdd 

私にとってこれはまったく無関係な単体テストであり、それを得る価値はほとんどないため、なぜ誰かがそれを書くのに時間を費やすのか理解できません。このコントローラーがブラウザーでメソッドを実行することで必要な型を返した場合、私は完全によく知っているでしょう。本当に、これにはテストが必要だと思いますか、それはなぜですか？ public class ConstituencyControllerTests { private ConstituencyController _constituencyController; private Mock<IConstituencyService> _IConstituencyServiceMock; public ConstituencyControllerTests() { _IConstituencyServiceMock = new Mock<IConstituencyService>(); } [Test] public async Task I_Check_For_Return_Type_And_Result() { _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object ); var result = await _constituencyController.Get(); var content = ( (dynamic)result ).Content; Assert.IsEmpty( content ); Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result …

22 unit-testing 

仕事中、私のプロジェクトの1つは主に外部クライアントから渡されたデータを取得し、データベースに保持することです。JPAを使用するJavaエンタープライズアプリであり、ほとんどのロジックはCRUD操作を中心に展開します。 バグの大部分は、何らかの形でJPAに関係しています。 例1：[保存]ボタンを2回クリックすると、JPAは同じエンティティをデータベースに2回挿入しようとし、主キー違反が発生する場合があります。 例2：データベースからエンティティを取得し、編集して、そのデータを更新しようとします。JPAは、古いインスタンスを更新する代わりに、新しいインスタンスを作成しようとする場合があります。 多くの場合、ソリューションはJPAアノテーションを追加/削除/変更する必要があります。また、DAOロジックの変更に関係する場合もあります。 単体テストとTDDを使用してコードに自信を持たせる方法がわかりません。ユニットテストとTDDの適合性が悪いのか、問題に近づいているのかがわかりません。 単体テストは、実行時にしかこれらの問題を発見できず、問題を再現するためにアプリサーバーに展開する必要があるため、不適切なように見えます。通常、データベースは関与する必要がありますが、これは単体テストの定義の外側にあると考えられます。これらは統合テストです。 TDDは、展開とテストのフィードバックループが非常に遅いため、非常に非生産的であるため、不適切なように思われます。deploy + testフィードバックループには3分以上かかります。これは、作成中のコードに関するテストを具体的に実行した場合にのみ発生します。すべての統合テストを実行するには、30分以上かかります。 この型の外側にはコードがあり、できる限りいつでも単体テストを行っています。しかし、バグの大部分と最大のタイムシンクは、常にJPAまたはデータベースに関係しています。 同様の別の質問がありますが、アドバイスに従えば、コードの最も不安定な部分（JPA）をラップし、それ以外のすべてをテストします。私の質問の文脈では、私は同じ悪い状況にいるでしょう。JPAをラップした後の次のステップは何ですか？IMOその質問は（おそらく）私の質問に答えるためのステップですが、それに対する答えではありません。

22 java  unit-testing  tdd  jpa 

すべてまたはほとんどのコーディングがスプリントの終了まで行われない場合、テストはコーディングと同じスプリント内でどのように処理されますか？（スプリント内の単一のPBIの「スープからナッツ」への開発とテストに言及しています。） 私がオンラインで見た回答のほとんどはQAの自動化に関係していますが、自動化されたテストを記録または作成するための機能的なUIが一般的に必要なので、それも実際には不可能です。機能を開発し、新しい要件を発見するにつれて進化し続けるストーリーボードしかありません。 私の場合、新しいデスクトップアプリケーションを開発しています。通常、デスクトップアプリは自動テストにあまり適していません。自動化された単体テストがいくつかありますが、QAの専門家が行う手動の機能/統合テストではありません。 ですから、私が今いるのは、私のスプリントが明日で終了するということです、私はまだコーディングを終える必要があります、そして私のQAの人々はまだテストするものが何もありません、そして私が手を持たずに私が彼らに与えるものをテストする方法がわかりません。 私はこのジレンマを持っている最初の人ではないと確信しています。 過去に、パイプラインを実行しました。現在のスプリントでは、テストチームが前のスプリントで実装された機能をテストします。私の現在の仕事では、PMはこのアプローチを「ウォーターフォール」と呼んでいます。

22 agile  testing  unit-testing  scrum  qa 

私は中規模企業のソフトウェアエンジニアです。TeamCityで実行されるかなり堅牢なテストプラットフォームがあります。すべてのチェックインで単体テストを実行し、毎日の単体テスト/ BVTを実行します。 問題は、大量の単体テストが失敗していることです。 ユニットテストが絶えず壊れていて、メンテナンスされていない場合、かなり頻繁にユニットテストの無意味さを引き出します。変更によってリグレッションが発生したかどうかを確認できないと、単体テストプラットフォームの価値のほとんどが失われます。 良い習慣の文化を作り出す種を植えたいです。壊れたときにテストを修正し、それらを価値あるものとみなし、他の作業とともにテストの修正を優先します。 私は賄ber（焼き菓子！）を試みましたが、単純に尋ねて、チームリーダーに話しました。誰もがそれは良いアイデアだと言いますが、私はそれについて何かをしている唯一の人であると思います。 他の人にテストの修正を奨励し、スプリント内でのテスト修正の優先順位付けを開始する最良の方法は何ですか？ これを尋ねる主観的な方法がなければ、どんなヒントでも喜んで受け入れます。

22 testing  unit-testing  tdd  culture  leadership 

ほとんどのソフトウェア開発者が同意する数少ない点の1つは、テストしない限り、正しく動作するためにコードに依存すべきではないということです。あなたがそれをテストしないなら、それはあなたが将来さらに仕事をすることになるだけの隠れたバグを持っているかもしれません。 通常のコードのテスト方法は理解していますが、テストコードをテストして、エラーが存在する場合に効果的にエラーを見つけて報告できることを確認するにはどうすればよいですか？私は個人的には、あるべきではないときに合格する誤ったテストケースを書くほど愚かであり、そもそも筆記テストの目的を破っています。幸いなことに、私は時間内にエラーを見つけて修正しましたが、テストのマントラによれば、それが機能することを確認するための独自のテストセットがなければ、テストスイートは完成しないようです。 これを行うための最良の方法は、バグのあるコードのテストが失敗することを確認することだと思われます。テストは「動作」します。これにより、2番目の質問が表示されます。テストケースでバグを確実にキャッチするために、バグを導入する良い方法は何ですか？文をランダムにコメントアウトしif-else、条件を否定して間違ったブランチを実行することを確認し、副作用などでコードの実行順序を変更して、テストが最もキャッチされるようになるまで一般的なバグ？プロの開発者は、テストが実際に行うべきことを実際に行うことをどのように検証しますか？彼らは単にテストが機能すると仮定していますか、それともテストにも時間をかけていますか？もしそうなら、彼らはどのようにテストをテストしますか？ 私は、人々がテストをテストし、実際に実際のコードを書くことのないテストのためにテストをテストするのにそれほど多くの時間を費やすべきだと提案しているわけではありませんが、 「メタテスト」の、そしてそれを行うための最良の方法に興味がありました。：D *「バグのない」コードをテストするときにテストが合格するかどうかを確認できましたが、テストの仕様としてコードを使用することはかなり逆に思えます...

22 testing  unit-testing  code-quality 

私は高校のロボットクラブのメンバーであり、ロボットのプログラミングを担当しています。さまざまな大人から聞き続ける提案の1つは、コードを検証するために単体テストを作成する必要があるということです。コードベースは少し大きくなってきており、バグをより迅速に見つけるのにユニットテストが本当に役立つことに同意します。 ただし、これをどのように実現できるかは完全にはわかりません。私の知る限り、ユニットテストは、関数（またはコードのサブシステム）を取得し、それに一連の入力を与えて、毎回同じ出力が得られることを確認することによって行われます。私が現在持っているコードは、大量のデータを処理するのではなく、ロボットのハードウェアコンポーネントを直接操作します。複雑さの大部分は、電子機器が正常であること、現時点のコードがロボットの実際のハードウェアと一致することなどを確認することから生じます。多くの場合、問題を確認できるのはロボット自体にコードをロードすることだけです。そしてそれを実行しようとしています。 拡張により、機械式デバイスを操作するためのコードの単体テストをどのように作成できますか？機械の動作を物理的に観察することによってのみエラーをキャッチできるように思えます。 それとも、単体テストがどのように機能するかを誤解しているだけですか？ （それが重要な場合、ここにコードがあります、それはC ++で書かれており、私はFRCに参加しています）

22 unit-testing 

クラスがあるとしましょう（不自然な例とその悪いデザインを許してください）： class MyProfit { public decimal GetNewYorkRevenue(); public decimal GetNewYorkExpenses(); public decimal GetNewYorkProfit(); public decimal GetMiamiRevenue(); public decimal GetMiamiExpenses(); public decimal GetMiamiProfit(); public bool BothCitiesProfitable(); } （GetxxxRevenue（）およびGetxxxExpenses（）メソッドには、スタブ化された依存関係があることに注意してください） 現在、GetNewYorkProfit（）とGetMiamiProfit（）に依存するBothCitiesProfitable（）を単体テストしています。GetNewYorkProfit（）とGetMiamiProfit（）をスタブしても大丈夫ですか？ そうしないと、GetNewYorkProfit（）とGetMiamiProfit（）をBothCitiesProfitable（）と同時にテストしているようです。GetxxxProfit（）メソッドが正しい値を返すように、GetxxxRevenue（）およびGetxxxExpenses（）のスタブを設定する必要があります。 これまでのところ、内部メソッドではなく外部クラスのスタブの依存関係の例を見てきました。 そして、それが大丈夫な場合、これを行うために使用すべき特定のパターンはありますか？ 更新 コアの問題を見逃しているのではないかと心配しています。これはおそらく私の貧弱な例のせいです。基本的な質問は、クラス内のメソッドが、その同じクラス内で公開されている別のメソッドに依存している場合、その他のメソッドをスタブ化しても大丈夫（または推奨）ですか？ たぶん何かが欠けているかもしれませんが、クラスを分割することが常に意味があるかどうかはわかりません。おそらく、もう1つの最小限の良い例は次のとおりです。 class Person { public string FirstName() public string LastName() public string FullName() } ここで、フルネームは次のように定義されます： public string …

22 unit-testing  mocking  stub 

通常、コーディング標準について話すとき、プログラム自体のコードを参照しますが、単体テストについてはどうですか？単体テストに固有の特定のコーディング標準ガイドラインはありますか？彼らは何ですか？

22 coding-standards  unit-testing 

「ユニットテストは、テスト中のコードのドキュメントの非常に重要なソースである」という流れの中でステートメントを読んだ回数を数えられません。それらが真実であることを否定しません。 しかし、個人的には、ドキュメントとしてそれらを使用していることを発見したことはありません。私が使用する典型的なフレームワークの場合、メソッド宣言はそれらの動作を文書化しており、それが私が必要とするすべてです。そして、ユニットテストでは、そのドキュメントに記載されているすべての内容に加えて、内部的なものがバックアップされる可能性があるため、一方では文書化を複製し、他方では無関係なものを追加する可能性があります。 質問は次のとおりです。ユニットテストはいつドキュメントとして使用されますか？コメントがすべてを網羅していないときは？開発者はソースを拡張しますか？そして、ドキュメント自体が公開できない有用で関連性のあるものを公開しますか？

22 unit-testing  documentation