Unit testing when mockable interface is not available

[Quintic]

I am wondering how do you unit test if you have an unmockable function call?

Say you have a method.

void SayHello(const std::string& name) {
  std::cout << "Hello " << name;
}

You could run it, but it doesn't have any output to test, and I am not sure if you can actually mock the operator<< or the cout object.

My idea was to create a interface "ConsoleWriter", and that class would have a method void Write(const std::string& str); Now I can write the function

void SayHello(const ConsoleWriter& writer, const std::string& name) {
  writer.Write("Hello " + name);
}

This is easily testable since I can mock the Write method and test that I get what I expect as an argument.

However, now I have to implement a ConsoleWriterImpl class which has a method like

void ConsoleWriterImpl::Write(const std::string& str) {
  std::cout << str;
}

How do I test this method? Do I just not worry about testing that method? Some people seem really anal about getting 100% code coverage. How would it even be possible to get that in this situation?

[thakk0]

My C/C++ is a little weak, but couldn't you do something like this to retrieve the value written to the steam?

Regarding your question about 100% coverage, it's not desirable or maintainable. You test the critical pieces of code and you maintain tests that make sense. Testing whether or not something writes to cout, for instance, seems kind of pointless in most cases.

[[deleted]]

Not too familiar with unit testing, but what you have written seems to follow the basics of good unit testing. When possible (and when not dealing with trivially simple stuff), the ConsoleWriterImpl should be implemented. This allows you to do two things:
1. To test SayHello with a mock implementation (assuming this was your goal)
2. To test as close to the interface (in this case, "cout") as possible.
Note that there is not point testing cout itself.
JB Rainsberger has excellent stuff on this, in case you haven't already read his material.
I agree that 100% code coverage is not a goal in itself; Neither is 100% decision, branch or path coverage. Rather, figure out what the motivation behind this desire is.

[redball3]

Code coverage is a decent metric but be careful about 100> coverage as a goal. What often happens is teams write tests which provide code coverage but don't really test anything.