本番コードでモッキングを使用する必要がありますか？

StackOverflow https://stackoverflow.com/questions/1211689

  •  06-07-2019
  •  | 
  •  

質問

本番環境でいくつかのコードをモックする必要がある状況があります。これは、コードの一部を半分の機能で動作させるためです。

（インターフェイスを実装するために）空のクラスを作成するか、moqのようなモックシステムを使用するかを選択する必要があります。

問題は、モッキングシステムがパフォーマンスを低下させる、または本番コードの読みやすさを損なうことですか？

更新
例：

interface IRocketSystem
{
   void LaunchTheRocket();
}

class SimulationRocketSystem:IRocketSystem
{
...
}

class RocketSystem:IRocketSystem
{
...
}

iは、実稼働環境にSimulationRocketSystemクラスがあり、そのクラスが小さく、本体に多くないことを発見しました。モックシステムには、このようなクラスを置き換えるコードが1行あります（新しいモック<！> lt; IRocketSystem <！> gt;（）。Object ）。

m笑の長所：
 プロジェクト内の空のクラスが少なくなります。

役に立ちましたか？

解決

ヌルオブジェクトのような音。 2つの理由から、このためにモックフレームワークを使用することは考えていません。

まず、読みやすさが損なわれます。適切な名前の空のクラスを使用してインターフェイスを実装し、そのクラス内の意図を文書化します。一方、モックフレームワークを使用する場合は、ドキュメントをコードのどこかに埋め込む必要があります。さらに、テストコードでモックを期待する傾向があり、モックを使用する意図を理解していないため、混乱を招きます。

第二に、誰かがインターフェースを変更した場合に何が起こるかを考慮する必要があります。メソッドが追加されたらどうなりますか？一部のフレームワークが行うように、デフォルトでnullを返す必要がありますか？メソッドがインターフェイスコントラクトに従って特定の戻り値を必要に返す場合はどうなりますか。具体的な実装がある場合、コンパイラは少なくともある程度保護します。モックフレームワークを使用している場合、運が悪いかもしれません。

他のヒント

モックオブジェクトは、正しく呼び出されたと断言できるので、テストに使用します。あなたが探しているのは、スタブまたはプロキシオブジェクトのようなものであるように思えます。

最終的には問題のクラスを実装するため、IMOのためにモックフレームワークを使用してもほとんど意味がありません。クラスを作成し、必要に応じて実装するだけではどうでしょうか。

空のクラスの何が問題になっていますか？

実際には、実際のクラスに置き換えられるため、実際のクラスから始めることもできます。

あらゆる種類の模擬コードを外部テストに置くことは悪いポリシーだと思います。

あなたはそれを「モック」と呼んでいますが、あなたがしていることは、懸念を適切に分離しているように思えます。

if文ではポリモーフィズムを使用して、何が起こるかを制御するのは良いことです。

例、ロギングをオプションにしたい場合。必須のアプローチは、boolean isLoggingを指定することです。その後、毎回if (isLogging) { ...logging code... }などのブール値を確認します。

ただし、代わりに実際のログコードを別のオブジェクトの懸念事項として分離する場合は、そのオブジェクトを目的の動作に設定できます。ロギングが無効になっていることと、実際にファイルに書き込むことを表すnullルーティングロガーを持つことに加えて、ファイルの代わりにデータベースに書き込むロギングオブジェクトを提供することもできます。ログファイルのローテーションとして。

単に優れたオブジェクト指向プログラミングです。

これはおそらく少し珍しいことなので、コメントなどでこれが必要な機能であることは明らかです。そうしないと、テストコードがどのように本番環境に到達したかについて、誰かが非常に混乱してしまいます！

パフォーマンスに関しては、相変わらず、非常に具体的であるため、これを測定する必要があります。ただし、作成していない機能をモックしているため、モックアウトされた実装よりもはるかに高速になる可能性が高いと推測します。最終的な機能の実装を提供すると、パフォーマンスが低下する可能性があるため、ユーザーを教育する必要があるかもしれません：-）

実際のソリューションは、既存のインターフェースにダミーの実装を提供し、後で実際の実装を提供することです。

パフォーマンスの問題について本当に知りません。しかし、私見、あなたは読みやすさに本当に注意しなければなりません。 1つ以上のインターフェイスを宣言し、2つの異なる方法で実装する方が良いとは思いませんか？

-編集

モッキングはより簡単で、使用するコードの行数は少なくなりますが、コードの学習曲線が増加します。新しい人が来てあなたのコードを見たら、彼は理解するのにより多くの時間を必要とします。個人的には、それはまだコードの実装されていない機能だと思います。しかし、別のインターフェイスの実装、または他の適切な設計上の決定があった場合、私は<！> quot; get it <！> quot;コードを変更すると、はるかに高速で安全に感じるでしょう。

まあ、それは個人的な意見です。コードは予想とは異なるパターンを使用します。 <！> quot; convention over configuration <！> quot;と似ています。規則を使用していない場合は、構成するのに苦労するはずです（この場合、文書化して、何をしているかを明確にします）。

私のアドバイス-実稼働環境に置かないでください。動作を遅くしたり、中断したり、失業させたりするようなものを本番環境に置かないでください：）

しかし、私が考えるよりも重要なことは、あなたの会社の方針は何ですか、そしてあなたの上司は何を考えていますか？このような決定を自分で行うことを考えないでください-CYAと呼ばれます。

  

空のクラスを記述するか、moqなどのモックシステムを使用する必要があります。

専用のファサード/アダプターコンポーネントでラップし、内部クラスを使用すれば十分です。空のクラスをシステムに渡す必要がある場合、問題があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top