How to test static private method of a class using Google test?

[Krish]

Class A{
public:
static void func(){
....
....
int ret = func1();
....
....
}
private:
static int func1();
};

How to test func1()?

[Alex Shaver]

In general, one uses unit testing to test "public" interfaces. ie, if I call "func()" my test is really what (in this case, side effects) is visible to external classes. 

So let's do a simpler case:

Class Foo{
public:
 static int cTimesAPlusB(int a, int b, int c){
  int sum = Foo::APlusB(a, b);
  return c * sum;
 }
private:
 static int APlusB(int a, int b){
  return a+b;
 }
};

A test for this case would be something like

Test(Foo, cTimesAPlusB){
 EXPECT_EQ(45, Foo::cTimesAPlusB(2, 3, 9));
}

See, the only result anyone can access is the result of cTimesAPlusB, so that's what we write a test around. That way, if we change it up in the future (say we used some other library to add a+b in a new implementation), the result should still stay the same. We don't care what the private members actually do, so long as the public results are the same.

"Ah, but my private function is really complicated and I really would like to know that it works on its own." I've found this to be true more often than not, in fact. This is where one can turn to the PIMPL idiom. (ie, we'd create an implementation class that moves the private function to public, and the interface class, A, would simply call that public function.) But I suspect that at this point it's important to understand why this class has a private static function to begin with.

[David Wallace]

"Ah, but my private function is really complicated and I really would like to know that it works on its own." I've found this to be true more often than not, in fact. This is where one can turn to the PIMPL idiom. (ie, we'd create an implementation class that moves the private function to public, and the interface class, A, would simply call that public function.) But I suspect that at this point it's important to understand why this class has a private static function to begin with.

Two other approaches that I've used in this case: (1): Make the private function protected instead of private.  Then you can create a testing subclass that wraps the protected function with a public method, and have your testing code instantiate the subclass and call that public method, without exposing the original function to all the users of the real object.  (2): Make your test fixture (or a single test) a friend of the original class, so it can call the private method directly.  This is discussed in the gtest documentation, in the Advanced Guide under the heading "Testing Private Code," which discusses the macros that support this, and issues you need to be aware of.

Dave W.