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

ユニットテストは、ソースコードの個々のユニットをテストして、それらが使用に適しているかどうかを判断する方法です。

2
ビジネスロジックが変更されたときに失敗した場合、単体テストは脆弱と見なされますか？
以下のコードをご覧ください。女性の性別を持つ人がoffer1に適格であるかどうかをテストします。 [Fact] public void ReturnsFalseWhenGivenAPersonWithAGenderOfFemale() { var personId = Guid.NewGuid(); var gender = "F"; var person = new Person(personId, gender); var id = Guid.NewGuid(); var offer1 = new Offer1(id,"Offer1"); Assert.False(offer1.IsEligible(person)); } この単体テストは成功します。ただし、今後「Offer1」が女性に提供されると、失敗します。 言うことは受け入れられますか？オファー1を取り巻くビジネスロジックが変更された場合、ユニットテストは変更されなければなりません。データベースによっては、ビジネスロジックが次のように変更される場合があります（一部のオファーでは）。 update Offers set Gender='M' where offer=1; そして、このようなドメインモデルの場合には： if (Gender=Gender.Male) { //do something } また、背後のドメインロジックが定期的に変更を提供する場合と、そうでない場合もあることに注意してください。
6
単体テストなしのアジャイル
作業しているコードベースのユニットテストカバレッジが0％である場合、「アジャイル開発」または「アジャイル手法」を適用していると主張することは理にかなっていますか？（そして、チームとして、あなたはそれについて何もしていません）。 それを明確にするために：私にとって、それは意味がありません。私の個人的な経験では、ユニットテストが実際に「アジャイル」（つまり、変更への対応、設計の改善、知識の共有など）を可能にする唯一のツールであり、TDDが唯一の手段であることがわかりました。 。 他の方法もあるかもしれませんが、どのように機能するかはまだわかりません。
7
面接プロセス中に与えられた過剰なプログラミングの割り当てを心配する必要がありますか？[閉まっている]
私は最近、会社に電話インタビューをしました。その電話インタビューの後、短いプログラミングの課題を完了するように言われました（小さなプログラムです。3時間以上かかることはありません）。割り当てを完了してコードを提出するように直接指示されているだけです。希望する言語を使用する完全な自由が与えられ、コードの入れ方を正確に教えられませんでした。 すぐにGithubに投げてテストスイートを作成し、Travis-CI（公開Githubリポジトリの無料の継続的統合）を使用してテストスイートを実行し、CMakeを使用してTravis-CIのLinuxメイクファイルをビルドすることを計画しました。そうすれば、Git、CMake、Travis-CIの使用方法、およびテストの作成方法を理解していることを実証できるだけでなく、Travis-CIページに簡単にリンクして、テストの出力を確認することもできます。インタビュアーにとっては少し便利になると思いました。 私はそれらの技術をよく知っているので、割り当てに時間を本質的に追加しません。 しかし、比較的単純なタスクでこれをすべて実行すると、見た目が悪くなるのではないかと少し心配しています。私にとってこれ以上の時間は追加されませんが、単純であるべきことに時間をかけすぎていると彼らに思わせたくありません。
6
「コードのテスト行」に対する「コードの機能行」の通常の比率は何ですか？
私はTDDアプローチにかなり慣れており、最初の実験では、1行の機能コードを記述することは、2〜3行のテストコードを記述することを意味します。したがって、1000 LOCを記述する場合、テストを含むコードベース全体は〜3500 LOCのようなものになります。 これは正常と見なされますか？あなたが書くコードの割合は何ですか？
6
単体テストと統合テスト：どうすれば反射になりますか
私のチームのすべてのプログラマーは、単体テストと統合テストに精通しています。私たちは皆それで働いてきました。すべてのテストが書かれています。私たちの中には、自分のコードに対する信頼感が向上したと感じている人もいます。 ただし、何らかの理由で、ユニット/統合テストを作成することは、チームのどのメンバーにとっても反射になりませんでした。実際のコードと同時にユニットテストを書いていないとき、私たちの誰も実際に気分が悪いことはありません。その結果、私たちのコードベースはユニットテストによってほとんど発見されず、プロジェクトはテストされずに本番に入ります。 それに伴う問題は、もちろん、プロジェクトが本番環境にあり、すでに正常に動作している場合、ユニット/統合テストを追加するための時間や予算を獲得することは事実上不可能であることです。 私のチームのメンバーと私はすでにユニットテスト（の値に精通している1、2）それは私たちの自然なワークフローにユニットテストをもたらす助けていないようです。私の経験では、単体テストやターゲットカバレッジを必須にすると、テストの品質が低下し、チームメンバーの速度が低下します。これは、これらのテストを作成するための自己生成の動機がないためです。また、圧力が緩和されるとすぐに、単体テストは記述されなくなります。 私の質問は次のとおりです。チーム内でダイナミック/モメンタムを構築し、自然にそれらのテストを作成および維持したい人を導くのに役立つ実験方法はありますか？
5
NInjectを使用して工場を建設する最良の方法は何ですか？
私は、MVC3でNInjectを使用した依存性注入にかなり満足しています。MVC3アプリケーションでの作業中に、私はNInjectを使用してカスタムコントローラー作成ファクトリを開発しました。そのため、作成されたコントローラーには、このコントローラーファクトリを介して依存関係が注入されます。 今、私はWindowsアプリケーションを開発し始めています、私はアプリケーション全体の依存性注入を使用したいと思います。つまり、ユニットテストを容易にするために、すべてのオブジェクトをNInjectを介して作成する必要があります。作成されたすべてのオブジェクトがNInject Factoryのみを通過するようにする必要があります。 たとえば、Button_Clickイベントで任意のWindowsフォームで次のように記述した場合： TestClass testClass = new TestClass() そしてTestClass、たとえば、上の任意の依存関係を持ってITest、それが自動的に解決されなければなりません。私が使用できることを知っています： Ikernel kernel = new StandardKenel() //AddBinding() TestClass testClass = kenel.get<TestClass>(); しかし、オブジェクトを作成するたびにこれを行うのは面倒です。また、開発者は特定の方法でオブジェクトを作成する必要があります。もっと良くできますか？ オブジェクト作成用の中央リポジトリを作成すると、すべてのオブジェクト作成でそのリポジトリが自動的に使用されますか？
9
アプリケーションを継承するときにすでに動作するコードの単体テストを書くことに価値はありますか？
明らかに、一部の古いアプリケーションは、そもそも記述された方法のために、単体テストを行うことができないか、非常に困難です。 しかし、おそらくユニットテストされる可能性のあるいくつかのヘルパーメソッドのように、それらのためにユニットテストを書くことをわざわざする必要がありますか？ つまり、それらは犬のように書くことができますが、論理が複雑に脆弱であっても、時間のテストはそれが本来の方法で機能することを証明しました。リファクタリングと言う場合にのみユニットテストを行う必要がありますか、時間があるときはいつでもユニットテストを作成する必要がありますか？ これを行うことに価値はありますか？ また、メソッドの定義が曖昧かもしれないことを考慮に入れて、特定の条件でメソッドのいくつかが実際に何をすべきかを研究する必要があるかもしれません。
5
TDDの使用を開始します。初心者向けのヒントはありますか？[閉まっている]
私はどのプロジェクトでも自動テストメカニズムを使用したことはなく、多くのことを失っていると感じています。私は自分自身を改善したいので、私はこのように無視してきたいくつかの問題に取り組み始め、SVNに固執する代わりにGitを試す必要があります。 TDDを学ぶ良い方法は何ですか？おそらくEclipseを使用してJavaでプログラムするでしょう。JUnitのことは聞いたことがありますが、他に検討すべき点があるかどうかはわかりません。
6
ユニットテストにどれくらいの時間を費やしていますか？
私が働いていた会社では、経営陣はユニットテストのコードカバレッジが99％以上でなければならないと主張しました。これは、コードよりも多くのテストを書くことになりました。実装に1日かかった単一のクラスのテストを書くのに、文字通り3日かかりました。 しかし、その結果、TDD、テストツール、プラクティスなどについて多くのことを学びました。 私がその後働いた会社では、単体テストは未知のものでした。それは誰かが前に聞いたことがあるかもしれないものでした。単体テストの概念を紹介するのに苦労しましたが、効果はありませんでした。 さて、自営業として、私は疑問に思う-あるどのくらいの時間は本当にユニットテストに費やす必要が？ほとんどがiPhone / Android開発者であるため、コードのどの部分をテストでカバーする必要がありますか？
17
プログラマーに単体テストを要求する必要がありますか？[閉まっている]
私は多くのITプロジェクトを購入する場所で働いています。私たちは現在、将来のプロジェクトの要求のためのシステム要件の標準を作成しています。そのプロセスでは、サプライヤーに自動化された単体テストを要求できるかどうかを議論しています。 適切な自動化された単体テストが、コードの品質と安定性を文書化する唯一の方法であると確信しています。他の誰もが、単体テストはサプライヤだけに関係するオプションの方法であると考えているようです。したがって、自動化された単体テスト、継続テスト、カバレッジレポート、単体テストの検査などは一切必要ありません。このポリシーは非常にイライラします。 私はここで完全に列から外れていますか？ 意見のいずれかの議論を提供してください。
5
テスト用にプライベートなものを内部/公開にするか、PrivateObjectのようなハックを使用しますか？
私はコードテストの初心者であり、assert以前は売春婦でした。ユニットテストで私を心配していることの1つは、そうでなければそうであったpublic（または少なくともinternal）フィールドを作成し、それらprivateを解除readonlyし、代わりにprivateメソッドprotected virtualを作成するなどが必要になることが多いということです... 私は最近、PrivateObjectクラスのようなものを使用して、リフレクションを介してオブジェクト内のすべてにアクセスすることで、これを回避できることを発見しました。しかし、これにより、テストの保守性が低下します（コンパイル時ではなく実行時に失敗します。単純な名前変更によって破損し、デバッグが難しくなります...）。これについてのあなたの意見は何ですか？アクセス制限に関する単体テストのベストプラクティスは何ですか？ 編集：たとえば、ディスク上のファイルにキャッシュを持つクラスがあり、テストでは代わりにメモリに書き込むことを検討してください。
26 c#  unit-testing 
4
.NETの最適な単体テストフレームワークとは何ですか？[閉まっている]
誰もが他のオプションを考慮せずにNUnitを使用しているように思えます。私はこれが理由だと思う： 誰もがすでにそれをよく知っているので、新しいAPIを学ぶ必要はありません。 NUnitで動作するように、継続的インテグレーションサーバーで既にセットアップされています。 私はこれについて間違っていますか？ 最近、自分のプロジェクトの1つでxUnitを使用することにしました。それは私にとって非常に理にかなっており、概念的にはNUnitからの明確な一歩のように思えます。 どのフレームワークが実際に最良であるかについて意見を聞きたいと思います-それを学習したり、自動テストを再構成したりすることを考慮しません。
6
Javaがパッケージアクセスをデフォルトにしたのはなぜですか？
私がこの質問をしているのは、彼らが非常に正当な理由でそれをし、ほとんどの人がそれを適切に使用していないと信じているからです。しかし、私の理論が本当なら、なぜプライベートアクセス修飾子が含まれているのか分かりません...？ デフォルトのアクセスが適切に使用されると、カプセル化を維持しながら、テスト容易性が向上すると考えています。また、プライベートアクセス修飾子を冗長にします。 デフォルトのアクセス修飾子は、他の世界から隠される必要があるメソッドに固有のパッケージを使用することで同じ効果を提供するために使用できます。テストフォルダー内のパッケージは、ソースフォルダーで宣言されているすべてのデフォルトメソッドにアクセスできます。 これが、Javaがパッケージアクセスを「デフォルト」として使用する理由だと思います。しかし、なぜプライベートアクセスも含まれているのか分かりません、有効なユースケースがあると確信しています...
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.