フレンドクラスを使用したC ++の単体テストプライベートメソッド

これは議論の余地があることを知っていますが、これが私にとって最良の選択肢であると仮定しましょう。私はこれを行うための実際のテクニックは何なのかと思っています。私が見るアプローチはこれです：

1）テストするメソッドのクラスのフレンドクラスを作成します。

2）friendクラスで、テストされたクラスのプライベートメソッドを呼び出すパブリックメソッドを作成します。

3）friendクラスのパブリックメソッドをテストします。

上記の手順を説明する簡単な例を次に示します。

#include <iostream>

class MyClass
{
  friend class MyFriend; // Step 1

  private:
  int plus_two(int a)
  {
    return a + 2;
  }
};

class MyFriend
{
public:
  MyFriend(MyClass *mc_ptr_1)
  {
    MyClass *mc_ptr = mc_ptr_1;
  }

  int plus_two(int a) // Step 2
  {
    return mc_ptr->plus_two(a);
  }
private:
  MyClass *mc_ptr;
};

int main()
{
  MyClass mc;
  MyFriend mf(&mc);
  if (mf.plus_two(3) == 5) // Step 3
    {
      std::cout << "Passed" << std::endl;
    }
  else
    {
      std::cout << "Failed " << std::endl;
    }

  return 0;
}

編集：

私のコードベースについて人々が疑問に思っている答えの1つに続く議論で私はわかります。

私のクラスには、他のメソッドによって呼び出されるメソッドがあります。これらのメソッドはいずれもクラスの外部で呼び出されるべきではないため、プライベートにする必要があります。もちろん、これらを1つの方法に入れることもできますが、論理的にははるかに優れています。これらのメソッドは単体テストを保証するほど複雑であり、パフォーマンスの問題のため、これらのメソッドをリファクタリングする必要がある可能性が非常に高いため、リファクタリングが何も壊さないことを確認するテストを行うとよいでしょう。テストを含めてこのプロジェクトに取り組んでいるのは私だけですが、チームで作業しているのは私だけではありません。

上記のことを言っても、私の質問は、プライベートメソッドの単体テストを書くのが良い習慣かどうかではありませんでしたが、フィードバックに感謝しています。

私が頻繁に使用する友人（ある意味では）の代替は、access_byとして知られるようになったパターンです。とても簡単です。

class A {
  void priv_method(){};
 public:
  template <class T> struct access_by;
  template <class T> friend struct access_by;
}

ここで、クラスBがAのテストに関与しているとします。これを書くことができます。

template <> struct access_by<B> {
  call_priv_method(A & a) {a.priv_method();}
}

その後、このaccess_byの特殊化を使用して、Aのプライベートメソッドを呼び出すことができます。基本的に、これは、Aのプライベートメソッドを呼び出したいクラスのヘッダーファイルにフレンドシップを宣言する責任を負います。また、Aのソースを変更せずに友人をAに追加できます。慣用的には、Aのソースを読む人には誰でも、Aがそのインターフェースを拡張するという意味でBを真の友人ではないことを示します。むしろ、Aのインターフェースは与えられたとおりに完全であり、BはAへの特別なアクセスを必要とします（テストが良い例であり、ブーストPythonバインディングを実装するときにこのパターンを使用しました。C++でプライベートである必要がある関数は実装のためにPythonレイヤーに公開します）。

テストするのが難しい場合、それはひどく書かれています

独自のテストを保証するほど複雑なプライベートメソッドを持つクラスがある場合、そのクラスはやり過ぎです。中には出ようとする別のクラスがあります。

テストするプライベートメソッドを1つまたは複数の新しいクラスに抽出し、パブリックにします。新しいクラスをテストします。

コードをテストしやすくすることに加えて、このリファクタリングはコードの理解と保守を容易にします。

プライベートメソッドをテストするべきではありません。限目。クラスを使用するクラスは、機能するために内部で使用するメソッドではなく、クラスが提供するメソッドのみを考慮します。

コードカバレッジが心配な場合は、パブリックメソッド呼び出しの1つからそのプライベートメソッドをテストできる構成を見つける必要があります。それができないなら、そもそもメソッドを持っている意味は何ですか？それは単に到達不能なコードです。

これを行うにはいくつかのオプションがありますが、モジュールのパブリックインターフェイスを（本質的に）変更して、内部実装の詳細にアクセスできるようにすることを念頭に置いてください（効果的にユニットテストを密結合クライアント依存関係に変換します。依存関係はまったくありません）。

• テストしたクラスにフレンド（クラスまたは関数）宣言を追加できます。

• テストしたコードを実行する#define private public前に、テストファイルの先頭に追加でき#includeます。ただし、テストされたコードが既にコンパイルされたライブラリの場合、これによりヘッダーが既にコンパイルされたバイナリコードと一致しなくなる可能性があります（そしてUBが発生します）。

• テストしたクラスにマクロを挿入し、後日そのマクロの意味を決定できます（コードをテストするための別の定義を使用）。これにより、内部をテストできますが、サードパーティのクライアントコードがクラスにハッキングすることもできます（追加する宣言で独自の定義を作成することにより）。

ここに疑わしい質問に対する疑わしい提案があります。リリースされたコードはテストについて知っている必要があるため、友人のカップリングは好きではありません。Nirの答えはそれを軽減する1つの方法ですが、テストに準拠するようにクラスを変更することはまだ好きではありません。

私は頻繁に継承に依存しないため、プライベートメソッドを保護し、必要に応じてテストクラスを継承して公開することがあります。現実には、パブリックAPIとテストAPIは異なる場合がありますが、プライベートAPIとは異なるため、バインドのようなものになります。

これが私がこのトリックに頼る種類の実用的な例です。私は埋め込みコードを作成しますが、ステートマシンにかなり依存しています。外部APIは必ずしも内部ステートマシンの状態を知る必要はありませんが、テストでは（おそらく）デザインドキュメントのステートマシン図への適合性をテストする必要があります。「現在の状態」のゲッターを保護されているものとして公開し、テストへのアクセスを許可して、ステートマシンをより完全にテストできるようにします。このタイプのクラスは、ブラックボックスとしてテストするのが難しいことがよくあります。

友人を使わなくても済むように、多くの回避策を使ってコードを書くことができます。

クラスを記述できますが、プライベートメソッドはまったくありません。その後、必要なことは、コンパイルユニット内で実装関数を作成し、クラスでそれらを呼び出して、アクセスする必要のあるデータメンバーを渡すことだけです。

そして、はい、将来ヘッダーを変更せずに署名を変更したり、新しい「実装」メソッドを追加したりできることを意味します。

価値があるかどうかにかかわらず、あなたは重量を量る必要があります。そして、あなたのヘッダーを誰が見るかによります。

サードパーティのライブラリを使用している場合、ユニットテスターへのフレンド宣言は表示されません。私も彼らのライブラリを構築したくないし、私がするときに彼らのテストを実行させたい。残念ながら、私が作成したサードパーティのオープンソースライブラリが多すぎます。

テストはライブラリの作成者の仕事であり、ユーザーの仕事ではありません。

ただし、すべてのクラスがライブラリのユーザーに表示されるわけではありません。多くのクラスは「実装」であり、適切に機能するための最良の方法で実装します。これらの場合、プライベートメソッドとメンバーはまだあるかもしれませんが、ユニットテスターに​​テストしてもらいたいです。したがって、堅牢なコードの迅速化につながる場合は、先に進んでそのようにしてください。そうする必要がある人にとっては保守が容易です。

クラスのユーザーがすべて自分の会社またはチーム内にいる場合、会社のコーディング標準で許可されていると仮定して、その戦略についてもう少しリラックスすることもできます。