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

クラス割り当て用のソートアルゴリズムをいくつか作成し、アルゴリズムが正しく実装されていることを確認するためのテストもいくつか作成しました。私のテストの長さは10行に過ぎず、3行ありますが、3行の間で変更されるのは1行だけなので、多くのコードが繰り返されます。このコードを、各テストから呼び出される別のメソッドにリファクタリングする方が良いでしょうか？その後、リファクタリングをテストするために別のテストを作成する必要はありませんか？一部の変数は、クラスレベルまで移動することもできます。テストクラスとメソッドは、通常のクラス/メソッドと同じルールに従う必要がありますか？ 以下に例を示します。 [TestMethod] public void MergeSortAssertArrayIsSorted() { int[] a = new int[1000]; Random rand = new Random(DateTime.Now.Millisecond); for(int i = 0; i < a.Length; i++) { a[i] = rand.Next(Int16.MaxValue); } int[] b = new int[1000]; a.CopyTo(b, 0); List<int> temp = b.ToList(); temp.Sort(); b = temp.ToArray(); MergeSort merge = new MergeSort(); …

11 testing  unit-testing  code-quality 

私は今朝いくつかのブログ投稿を読んでいて、これに出くわしました： Customerインターフェースを実装する唯一のクラスがCustomerImplである場合、実際には実行時に代用するものがないため、ポリモーフィズムと代替性はありません。それは偽の一般性です。 インターフェースを実装すると複雑さが増し、実装が1つしかない場合は、不必要な複雑さが加わると主張するかもしれません。必要以上に抽象的なコードを記述することは、「投機的一般性」と呼ばれるコードの匂いと見なされることがよくあります（投稿でも言及されています）。 しかし、TDDを使用している場合、インターフェイス実装または他のポリモーフィックオプションの形式であるかどうかにかかわらず、クラスを継承可能にし、そのメソッドを仮想にすることで、その投機的な一般性なしにテストダブルを作成することはできません。 それでは、このトレードオフをどのように調整するのでしょうか？テスト/ TDDを促進するために投機的に一般的であることは価値がありますか？テストdoubleを使用している場合、これらは2番目の実装としてカウントされ、一般性が推測されなくなりますか？具体的な協力者のモックを可能にする、よりヘビーなモックフレームワークを検討する必要があります（たとえば、C＃の世界でのMolesとMoq）。または、具体的なクラスでテストし、デザインが自然にポリモーフィズムを必要とするときまで、「統合」テストと考えられるものを記述する必要がありますか？ 私はこの問題に関する他の人々の見解を読んでみたいです-あなたの意見を事前に感謝します。

11 design  unit-testing  code-smell  polymorphism 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 私は常に作業コードを書き直すことに懐疑的でした-コードの移植もこれに例外ではありません。ただし、TDDと自動テストの出現により、コードの書き直しとリファクタリングがはるかに合理的になりました。 古いコードの移植に使用できるTDDツールがあるかどうか、誰もが知っていますか？理想的には、次のことができます。 合格する（またはバグを見つけた場合は失敗する）古いコードの言語に依存しない単体テストを作成します。 失敗した他のコードベースで単体テストを実行します。 古いコードを見ずにテストに合格する新しい言語でコードを記述します。 別の方法として、ステップ1を「言語1でユニットテストを書く」と「言語2にユニットテストを移植する」に分割します。これにより、必要な労力が大幅に増加し、ポート（つまり、このコードベースでの継続的な統合の利点は得られません）。 編集：StackOverflowでこの質問に注目する価値があります。

11 unit-testing  language-agnostic  porting 

最近、Cyclomatic Complexityに出くわしました。それをよりよく理解したいと思います。 複雑さの計算に使用されるさまざまな要因の実用的なコーディング例は何ですか？具体的には、Wikipediaの方程式についてM = E − N + 2P、次の各用語の意味をよりよく理解したいと思います。 E =グラフのエッジの数 N =グラフのノードの数 P =接続されたコンポーネントの数 EまたはNのいずれかが、コードブロック内の決定ポイント（if、else、for、foreachなど）の数であると思われますが、どちらがどちらを意味するのかはよくわかりません。また、Pは関数呼び出しとクラスのインスタンス化を指すと推測していますが、私が見ることができる明確な定義はありません。誰かがそれぞれの明確なコード例でもう少し光を当てることができれば、それは助けになるでしょう。 フォローアップとして、Cyclomatic Complexityは、100％パスカバレッジに必要な単体テストの数と直接相関していますか？例として、複雑度4のメソッドは、そのメソッドをカバーするために4つのユニットテストが必要であることを示していますか？ 最後に、正規表現は循環的複雑度に影響しますか？

11 unit-testing  cyclomatic-complexity 

ユニットテストケースの作成を自動化するために使用できるいくつかの戦略は何ですか？少なくともまともなテストケーススケルトンを生成できるようにするには、各クラスでどの側面を検討する必要がありますか？ 包括的な自動ソリューションは実用的ではないことがわかりますが、少なくともスケルトンを作成することで、テストの作成を少しスピードアップしたいと思います。私はコード例を探しているのではなく、おそらくどこから始めたらいいか、このようなことをした例がいくつかあるので、彼らがどのようにアプローチし、何が可能かを見ることができます。 特に、PHPで単体テストスケルトンを作成する方法に興味があります。これは、たとえば完全なタイプヒンティングなど、他の言語が提供するすべてのツールを提供するものではありません。

11 php  unit-testing 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 ユニットテストで優れたプレゼンテーション（スライド+オーディオまたはビデオを推奨）を探していましたが、見つけるのは書籍とブログ投稿だけです。プレゼンテーションは茶色のバッグランチで表示されるため、50分を超えないようにしてください。私が探しているのは、一般的な概念または.NETプラットフォームでそれを行う方法です。 その説明に合ったプレゼンテーションを推奨できますか？

11 .net  unit-testing  presentation 

TDDやBDDのプロジェクトに参加したことがない、またはTDDを行っていると言っているが、それとはかなりかけ離れていると言っても、これらは私が考えていることで、できる限り読みたい約。 質問に戻ります。BDDを実行しているときは、最初に「テスト」を記述して、失敗させる必要があります。そして、その機能またはあなたがそれを呼ぶものを実装します。しかし、これを極端に考えれば、これはある種のトップダウン開発ではないでしょうか？UIを見て、「この機能/動作をここに追加したい」と言っています。次に、UIを修正して、その機能とUIをサポートするコードを実装します。この時点では、ビジネスロジックやデータアクセスロジックを実装しておらず、動作を実装しただけです。最初にテストを書く代わりに、私が目指しているのは、最初にUIコードを書くことです。UIコードを使用してビジネスでサポートする必要があるものを定義するため、場合によっては、データアクセス層とビジネス層で同じコードになるはずです。 もちろん、機能を機能で機能することを確認するために使用されるテストでこれを補完する必要があります。 何かご意見は？

11 unit-testing  tdd 

テストを書くとき、誰かがデータをモックするだけでなくインメモリデータベースを使用したいのはなぜですか？ インメモリデータベースは、自分のリポジトリをテストするのに役立つことがわかりました。ただし、フレームワーク（Spring Dataなど）を利用する場合、リポジトリのテストはフレームワークのテストであり、実際にはアプリケーションロジックではありません。 ただし、モッキングはより高速に見え、単体テストやTDDを作成するときに一般的に採用されているのと同じパターンに従っています。 それで私は何が欠けていますか？インメモリデータベースが役立つのはいつ/なぜですか？

11 unit-testing  testing  tdd  mocking 

関数Bをテストする場合、その関数Bを呼び出す関数Cをテストします。つまり、その関数Bを呼び出す関数Cをテストするためのテストプログラムを作成しても、テストメソッドはユニットテストなどと呼ばれますか？ ターゲット関数を呼び出す関数を間接的にテストすることが望ましい場合、および関数を直接テストすることが望ましい場合はいつですか？

11 unit-testing  testing 

私は1年前からTDDを行っていますが、TDDにはかなり満足しています。テストスイートなど、すべてが大好きです。しかし、最近私は多くの模擬通話検証を行っていることに気づきました。たとえば、リポジトリが挿入されるサービスがあります-単体テストでは、リポジトリのモックを渡し、テストしているメソッド内で呼び出されていることを確認します。次に、返された結果が正しいかどうかを確認します（別のテストで）。私の単体テストは実装の詳細に非常に結びついているので、これは間違いなく間違いだと感じています。「振る舞い」をテストするべきだと聞いたことがありますが、多くの状況では... emm-不可能ですか？あなたが持っている場合voidたとえば、通常は副作用をテストします。つまり、これを実証できる単純なコード型を簡単に示すことができますが、私見では、私たちが作成する実際のプログラムにはあまり反映されていません。私が間違っているのは何ですか？この種のテストは一種のアンチパターンですか？これについてのあなたの意見をいただければ幸いです。TDDに関しては、まだ初心者です。

11 unit-testing  tdd  code-smell  anti-patterns 

私の意見では、単体テストケース自体がコードのドキュメントとして機能します。私の会社では、単体テストケースの上に詳細なjava docコメントを書いてほしいと思っています。そうする必要がありますか？そんなコメントはありますか？

11 unit-testing  documentation 

現在、プロジェクトで単体テストケースを作成しています。データベースメソッドの実装が存在し、正常に動作しています。この場合、モックオブジェクトを作成する必要があるのはなぜですか？具体的な理由はありますか？DAO実装を直接テストできないのはなぜですか？

11 unit-testing 

最近、修士プログラムのソフトウェアエンジニアリングコースの最終試験を受けましたが、試験の質問の1つは次のとおりです。 Unit Testing is considered: a. White-box Testing b. Black-box Testing c. Either 7年間のソフトウェア開発経験の中で、ユニットテストは常にホワイトボックスアプローチを採用してきました。テスターは、テストを作成する間、常にユニットの実装について完全な知識を持っています。ブラックボックステストは、統合、システム、および受け入れテストという形で常に後になります。 ただし、（教授によると）試験に対する正解は、単体テストはホワイトボックステストまたはブラックボックステストのいずれかであるということです。 私はいくつかの調査を行いましたが、多くの場合、「ブラックボックスユニットテスト」は、コードが作成される前にユニットテストが記述されるテストファーストアプローチを記述するために使用されているようです。しかし、私の意見では、これはまだホワイトボックステストです。実装はまだ存在していませんが、テストを書いている人は一般に、ソースコードの実装方法についてかなり良い考えを持っています。 ブラックボックスユニットテストのしくみ（本当にそうである場合）とホワイトボックスユニットテストとの違いを誰かに説明してもらえますか？

11 unit-testing  testing  tdd 

テストとの継続的な統合は、常に「出荷可能な」コードがチェックインされていることを確認するのに役立ちます。 ただし、包括的なテストスイートを維持することは非常に難しく、多くの場合、ビルドにバグがあるように感じます。 CIパイプラインテストに自信を持たせるには、どのくらいのテストが必要ですか。十分なテストがあるかどうかを判断するために、ある種のメトリックを使用していますか？

10 unit-testing  testing  continuous-integration 

最近気付いたのは、次のタイプのプロジェクトを実行しているときです。 プロジェクトを始めるとき MVP /プロトタイプの作業 完全に定義されていない機能を追加する 小規模プロジェクトでの作業 参考までに、私は現在、いくつかのコメントとすべての空白を含む、現在〜1k行のコードがあるPythonプロジェクトに取り組んでいます。 私は、コードの最初の書き込みの統合テスト、仕事にそれが非常に簡単に見つけて、その後、それ一度APIは、多少のユニットテストを追加することで、実際に作業を硬化させます。私のmain関数で実行できるテストの種類、いわば、何よりも「エンドツーエンド」です。 これは、APIがかなり急速に変化しているときにユニットテストが本当に煩わしいためです。これは、上記の条件のいずれかまたはほとんどに一致するプロジェクトで作業している場合によくあります。 このアプローチは良いアプローチですか？これらのタイプのプロジェクトの最初に単体テストと統合テストのどちらを開始するかを決定するとき、どの基準を考慮する必要がありますか？APIがより強固になる前に、この種のプロジェクトを単体テストすることの価値を見逃していますか？

10 design  unit-testing  integration-tests