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

TDDには、アレンジアサート（AAA）構文があります。 [Test] public void Test_ReturnItemForRefund_ReturnsStockOfBlackSweatersAsTwo_WhenOneInStockAndOneIsReturned() { //Arrange ShopStock shopStock = new ShopStock(); Item blackSweater = new Item("ID: 25"); shopStock.AddStock(blackSweater); int expectedResult = 2; Item blackSweaterToReturn = new Item("ID: 25"); //Act shopStock.ReturnItemForRefund(blackSweaterToReturn); int actualResult = shopStock.GetStock("ID: 25"); //Assert Assert.AreEqual(expectedResult, actualResult); } BDDの記述テストでは、同様の構造を使用しますが、Given When Then（GWT）構文を使用します。 [Given(@"a customer previously bought a black sweater …

13 c#  unit-testing  tdd  bdd 

私は大企業で働いており、何千ものJUnitテストがある大規模なJavaアプリケーションを担当しています。私がこの役割に移行して以来、200〜300のテストが壊れています（何年も壊れている可能性があります）。テストは古くて壊れやすく、通常はライブサンドボックスデータで終わるスパゲッティの依存関係の混乱です。 私の目標はテストを100％合格することで、単体テストの失敗でビルドを中断できますが、失敗したテストに対処するまではできません。メンテナンス予算は主にサポートのためであるため、予算はほとんどありませんが、私のチームは、問題の少ないフルーツテスト（主に構成/ローカルリソースの問題）を特定して修正しました。 ベストプラクティスに関する意見はありますか？テストは価値があるとは思いませんが、テストしているものが何なのか、掘り下げなければ動作しない理由もわかりません。おそらく時間とお金がかかるでしょう。 壊れたテストのステータスを既知のもので文書化し、壊れたテストを完全に削除または無視し、優先順位の低いバグ/作業項目を入力して調査および修正する必要があると考えています。その後、100％になり、他のテストから真の価値を引き出し始めます。メンテナンス/リファクタリングの失敗があれば、それらを再び拾い上げることができます。 最善のアプローチは何でしょうか？ 編集：これはこの質問とは異なる質問だと思います。なぜなら、今後書くべきテストの明確な方向性があるからです。しかし、現在の大規模なテストセットが意味を持つようになる前に対処するために、レガシーの失敗したテストを継承しました。

13 java  unit-testing  legacy 

例から始めましょう。 たとえば、exportDBスキーマに大きく依存するというメソッドがあります。また、「大きく依存する」ということは、特定のテーブルに新しい列を追加すると、頻繁に（非常に頻繁に）対応するexportメソッドが変更されることを知っています（通常、エクスポートデータにも新しいフィールドを追加する必要があります）。 プログラマーは、exportメソッドを変更することを忘れることがよくあります。これを確認する必要があるかどうかは明確ではないからです。私の目標は、プログラマーがメソッドを見るのを忘れたのか、エクスポートデータにフィールドを追加したくないだけなのかを明確に決定するようプログラマーに強制することexportです。そして、私はこの問題の設計ソリューションを探しています。 私には2つのアイデアがありますが、どちらにも欠点があります。 スマートな「すべてを読む」ラッパー すべてのデータが明示的に読み取られるようにするスマートラッパーを作成できます。 このようなもの： def export(): checker = AllReadChecker.new(table_row) name = checker.get('name') surname = checker.get('surname') checker.ignore('age') # explicitly ignore the "age" field result = [name, surname] # or whatever checker.check_now() # check all is read return result そのため、読み取られなかった別のフィールドが含まれてcheckerいるかどうかをアサートしtable_rowます。しかし、このことはすべて重そうに見え、（おそらく）パフォーマンスに影響します。 「その方法を確認する」unittest 最後のテーブルスキーマを記憶し、テーブルが変更されるたびに失敗するunittestを作成するだけです。その場合、プログラマーは「exportメソッドをチェックアウトするのを忘れないでください」のようなものを見るでしょう。警告プログラマーを非表示にするには、問題をチェックアウトしexport、手動で（別の問題です）新しいフィールドを追加してテストを修正します。 私には他にもいくつかのアイデアがありますが、それらは実装するのが面倒で、理解するのが難しすぎます（そして、プロジェクトをパズルにしたくないのです）。 上記の問題は、私が時々遭遇するより広範なクラスの問題の例です。いくつかのコードやインフラストラクチャをバインドしたいので、それらのいずれかを変更すると、すぐにプログラマに別のコードをチェックするよう警告します。通常、一般的なロジックの抽出や信頼性の高い単体テストの作成などの簡単なツールがありますが、より複雑なケースのツールを探しています。

13 design  design-patterns  architecture  unit-testing 

少し前に、私は見つけることができないStack Overflowの回答で、パブリックAPIをテストする必要があることを説明した文を読み、著者はインターフェイスをテストする必要があると言いました。また、メソッドの実装が変更された場合、テストケースを変更する必要はありません。これを行うと、テスト中のシステムが機能することを確認する契約が破られるため、著者は説明しました。つまり、メソッドが機能しない場合はテストが失敗しますが、実装が変更されたためではありません。 私たちがock笑について話すとき、これは私の注意を呼びました。モックはテスト対象システムの依存関係からの期待呼び出しに大きく依存しているため、モックはインターフェイスではなく実装と密接に結合されています。 モックとスタブの調査中、いくつかの記事は、依存関係からの期待に依存しないため、モックの代わりにスタブを使用する必要があることに同意しています。 私の質問は次のとおりです。 モックはオープン/クローズの原則に違反しますか？ 最後の段落のスタブを支持する議論に欠けているものはありますか？ もしそうなら、いつスモックを作成するのに適したユースケースになり、スタブを使用するのに適したユースケースになりますか？

13 unit-testing  solid  mocking  open-close  stub 

他の多くのクラスがコードのあらゆる場所で使用する一般的な静的メソッドを提供するユーティリティクラスがあるとします。 ユーティリティテストのいずれかが合格しなかった場合にテストが失敗するように、ユーティリティのコンシューマ向けのユニットテストをどのように設計しますか？あなたはそれを行うことができますか、ユーティリティクラスのテストがすべてグリーンであるかどうかを自分で確認する必要がありますか？ たとえば、メッセージパーサーによって使用される（またはその出力）メッセージスプリッターユーティリティがあります。メッセージパーサーがテストされる前に、メッセージスプリッターが正しく動作することを確認したいと思います。 両方のテストを作成しましたが、それらをリンクし、1つのテストを他のテストの結果に依存させる方法はありますか？ これに適したタグが見つかりませんでしたが、Visual Studioの単体テストエンジンを使用しています。

13 c#  design  unit-testing 

というインターフェイスがありますIContext。この目的のために、以下を除いて、実際に何をするかは重要ではありません。 T GetService<T>(); このメソッドが行うことは、アプリケーションの現在のDIコンテナを調べ、依存関係を解決しようとすることです。かなり標準だと思います。 ASP.NET MVCアプリケーションでは、コンストラクターは次のようになります。 protected MyControllerBase(IContext ctx) { TheContext = ctx; SomeService = ctx.GetService<ISomeService>(); AnotherService = ctx.GetService<IAnotherService>(); } そのため、各サービスのコンストラクターに複数のパラメーターを追加するのではなく（アプリケーションを拡張する開発者にとってこれは非常に面倒で時間がかかるため）、このメソッドを使用してサービスを取得しています。 今、それは間違っていると感じています。しかし、私が現在頭の中でそれを正当化している方法はこれです- 私はそれをあざけることができます。 できます。IContextControllerをテストするためにモックアップすることは難しくありません。とにかくする必要があります： public class MyMockContext : IContext { public T GetService<T>() { if (typeof(T) == typeof(ISomeService)) { // return another mock, or concrete etc etc } // etc …

13 c#  unit-testing  asp.net-mvc  dependency-injection 

Webベースの教育用ゲームを継承しました。過去1年間、コードの安定化と新しい機能の追加に取り組んできました。ほとんどのロジックはフロントエンドにあるため、バックエンドの単体テストは有用ですが、コードのごく一部をカバーします。 ゲームは複雑になり始めています。各ゲームには2つの異なるモードがあり、モードによってゲームの動作は異なります。ゲームのプレイに影響するさまざまなフラグもあります。 私はもう10年以上アプリケーション開発者であり、これは私を困惑させます。企業の世界では、アルゴリズムは常に同じように機能します。アルゴリズムの単体テストを作成します。値42を期待し、その値を取得しないとエラーになります。 ゲームに関しては、私は迷っています。それらをテストするにはどうすればよいですか？テスターを利用できます。単体テストの作成に時間を費やすことができます。 テスターは...信頼できません。それらは問題を根絶するのに最適ではなく、私はそれらに最善の方向性を与えていません。リリースサイクルごとに膨大な時間を費やしてゲームのあらゆる組み合わせや組み合わせをテストするのではなく、それらをリソースとしてどのように使用すればよいですか？ 単体テストは制限されているようです。ほとんどのロジックはjavascript（およびスパゲッティコードを継承）であるため、CucumberやSeleniumなどのフロントエンドスイートを使用して、特定の機能が動作することを確認できます。 それが最善の戦略ですか？ゲーム会社はどのようにゲームをテストしますか？ 「複雑なゲームのテスト駆動開発」という質問（サイト上の他の記事も参照）を読みましたが、探しているものには対応していません。テスト方法の具体的な例ではなく、戦略を求めています。

13 unit-testing  testing  tdd  games 

価値の観点から、私は実際にユニットテストの2つのグループを見ています： 自明でないロジックをテストするテスト。それらを（実装前または実装後のいずれかで）記述すると、いくつかの問題/潜在的なバグが明らかになり、将来ロジックが変更された場合に備えて自信を持てるようになります。 非常に簡単なロジックをテストするテスト。これらのテストは、テストよりもドキュメントコード（通常はモックを使用）に似ています。これらのテストのメンテナンスワークフローは、「一部のロジックが変更され、テストが赤になりました-このテストを作成した神に感謝します」ではなく、「一部の些細なコードが変更され、テストが偽陰性になりました-利益を得ることなくテストを維持（書き換え）する必要があります」 。ほとんどの場合、これらのテストは維持する価値がありません（宗教上の理由を除く）。そして、多くのシステムでの私の経験によると、これらのテストはすべてのテストの80％に相当します。 私は他の人が値によるユニットテストの分離のトピックでどう思うか、それが私の分離にどのように対応するかを見つけようとしています。しかし、私が主に目にしているのは、フルタイムのTDDプロパガンダか、テストは役に立たず、ただ書くだけのコードプロパガンダです。途中で何かに興味があります。あなた自身の考えや記事/論文/本への言及を歓迎します。

13 unit-testing  tdd 

いくつかのことを行うこのクラスを作成しました（おそらくこれは単一責任原則の違反です）。私はプロジェクトのいくつかの他の部分が必要であることを今実感作品そのロジックのを、私はそれを公開するつもりだ方法は、私のオリジナルテスト対象システムのうち、クラスを抽出することです。 テストコードを変更せずにこれを行うことができると予想していますが、完了したら、テストはユニットテストではなくなったと主張できます。元のクラスと抽出したクラスをテストします。つまり、テストケースは1つですが、テスト対象のシステムは2つになります。 完了したら、テストコードをリファクタリングすることになっていますか？IE：ExtractedClassTestを作成し、関連するすべてのテストをOriginalClassTestからそこに移動しますか？これは少しリスクが高いようです：プロセスのカバレッジを失う可能性があります。テストを移動するほど簡単ではないかもしれません。等 一方、OriginalClassTestをそのままにしておくと、これがテストメンテナンスの問題であることがわかります。ExtractedClassのテストがどこにあるかを見つけるのは少し混乱するでしょう。あなたの第一印象は、それが存在しないということです。量産コードのリファクタリングが多くなると、これは深刻な問題になる可能性があります。 私はTDDが初めてなので、専門家のアドバイスをお願いします。ありがとう！

13 programming-practices  unit-testing  tdd  integration-tests 

だから、私は少し前に書いた認証モジュールを持っています。今、私は自分のやり方のエラーを見、それのための単体テストを書いています。単体テストを書いている間、私は良い名前とテストする良い領域を思いつくのに苦労しています。例えば、私は次のようなものを持っています RequiresLogin_should_redirect_when_not_logged_in RequiresLogin_should_pass_through_when_logged_in Login_should_work_when_given_proper_credentials 個人的には、「適切」に見えても、少しthoughいと思います。また、テストをスキャンするだけでテストを区別するのに苦労しています（失敗したものを知るには、メソッド名を少なくとも2回読む必要があります） だから、機能を純粋にテストするテストを書く代わりに、シナリオをカバーするテストのセットを書くかもしれないと思った。 たとえば、これは私が思いついたテストスタブです： public class Authentication_Bill { public void Bill_has_no_account() { //assert username "bill" not in UserStore } public void Bill_attempts_to_post_comment_but_is_redirected_to_login() { //Calls RequiredLogin and should redirect to login page } public void Bill_creates_account() { //pretend the login page doubled as registration and he made an …

13 design-patterns  .net  testing  unit-testing  user-story 

私は単体テストを行っており、クラスの1つでメソッドの1つからメールを送信する必要があるため、コンストラクター注入を使用Zend_Mailして、Zendフレームワークにあるクラスのインスタンスを注入します。 現在、一部の人々は、ライブラリが十分に安定しており、頻繁に変更されない場合、それをラップする必要はないと主張します。したがって、それZend_Mailが安定しており、変更されず、私のニーズに完全に適合すると仮定すると、そのためのラッパーは必要ありません。 次にLogger依存する私のクラスを見てみましょうZend_Mail： class Logger{ private $mailer; function __construct(Zend_Mail $mail){ $this->mail=$mail; } function toBeTestedFunction(){ //Some code $this->mail->setTo('some value'); $this->mail->setSubject('some value'); $this->mail->setBody('some value'); $this->mail->send(); //Some } } ただし、ユニットテストでは、一度に1つのコンポーネントをテストする必要があるため、Zend_Mailクラスをモックする必要があります。さらに、クラスが抽象ではなく結石に依存するようになったため、依存関係反転の原則に違反してLoggerいます。 Loggerラップせずに単独でテストするにはどうすればよいZend_Mailですか？ コードはPHPにありますが、答えはそうである必要はありません。これは、言語固有の機能というよりも設計上の問題です

13 design  object-oriented  unit-testing  tdd  solid 

現在のプロジェクトでは、コードに浸透していると思われる一定量のバグを回避するために、開発サイクルにユニットテストを組み込むことを望んでいます。問題は、スパゲッティコードの95％が手続き型であり、ユニットテストを一度も行ったことがないことです（ユニットテストの経験はすべて、OOPコードを使用したことです） 簡単に言えば、私の質問は、現在のコードベースで単体テストを進めるのが賢明でしょうか、それともアプリケーションが適切なOOPフレームワークに移行されるまで延期することを提案するのでしょうか？ PS：私はこの問題を言語にとらわれないものとしてスタイル付けようとしましたが、問題のアプリケーションはPHPとjavascriptを使用していると述べると、経験からこの発生はこのようなアプリケーションで最も多く発生するため、この質問に答えることができるより具体的な回答を提供するのに役立つと感じています。

13 object-oriented  unit-testing  procedural 

単体テストが実行されないようにする方法はありますが、失敗した単体テストをチェックすることの価値は何ですか？ 簡単な例を使用します：大文字と小文字の区別。現在のコードでは大文字と小文字が区別されます。メソッドへの有効な入力は「Cat」であり、Animal.Catの列挙を返します。ただし、メソッドの目的の機能では大文字と小文字を区別しないでください。したがって、記述されたメソッドが「cat」に渡された場合、Animal.CatではなくAnimal.Nullのようなものを返す可能性があり、ユニットテストは失敗します。簡単なコード変更でこの作業が可能になりますが、より複雑な問題の修正には数週間かかる場合がありますが、単体テストでバグを特定することはそれほど複雑ではありません。 現在分析中のアプリケーションには、「機能する」4年間のコードがあります。ただし、単体テストに関する最近の議論では、コードに欠陥が見つかりました。明示的な実装ドキュメント（大文字と小文字を区別するかどうかなど）、または現在の呼び出し方法に基づいてバグを実行しないコードのみが必要なものもあります。ただし、バグが発生する有効な入力である特定のシナリオを実行する単体テストを作成できます。 誰かがコードを修正できるようになるまでバグを実行する単体テストをチェックインすることの価値は何ですか？ 実行されたテストに基づいてビルドが成功したかどうかを判断するために、このユニットテストにignore、priority、categoryなどのフラグを設定する必要がありますか？最終的には、誰かが修正したらコードを実行するために単体テストを作成する必要があります。 一方では、特定されたバグが修正されていないことを示しています。一方、ログには何百もの失敗した単体テストがあり、コードチェックインによる失敗と失敗の組み合わせを見つけるのは困難です。

13 unit-testing 

クラスのJUnitユニットテストを書いています。 メソッドごとに個別のクラスを用意するのが良いのでしょうか、それとも実際のクラスごとにテストクラスを1つだけ用意するのがよいのでしょうか。

13 java  object-oriented  unit-testing  testing  junit 

テストを作成していて、テストに合格する必要があり、独自の機能に分離する必要がある追加の機能が必要であることに気付いたとき、何をしますか？その新しい関数もテストする必要がありますが、TDDサイクルでは、テストを失敗させ、成功させてからリファクタリングするように指示されています。テストに合格しようとしているステップにいる場合、実装する必要がある新しい機能をテストするために、別の失敗したテストを開始することは想定されていません。 たとえば、関数WillCollideWith（LineSegment）を持つポイントクラスを作成しています。 public class Point { // Point data and constructor ... public bool CollidesWithLine(LineSegment lineSegment) { Vector PointEndOfMovement = new Vector(Position.X + Velocity.X, Position.Y + Velocity.Y); LineSegment pointPath = new LineSegment(Position, PointEndOfMovement); if (lineSegment.Intersects(pointPath)) return true; return false; } } LineSegment.Intersects（LineSegment）関数が必要だと気づいたとき、CollidesWithLineのテストを書いていました。しかし、この新しい機能を作成するために、テストサイクルで実行していることを停止する必要がありますか？これは「赤、緑、リファクタリング」の原則を破っているようです。 lineSegments IntersectをCollidesWithLine関数内で検出し、動作後にリファクタリングするコードを記述する必要がありますか？LineSegmentからデータにアクセスできるので、この場合はうまくいきますが、その種のデータがプライベートな場合はどうでしょうか？

13 unit-testing  tdd