I\'m trying to understand the purpose of google-mock
, Google\'s C++ mocking framework.
I have already worked with gtest
earlier, but still I ca
Software units do not live in green meadows. They very often need some counterparts to do the work. In real system, these counterparts belong to the system itself. In the unit tests they are replaced with mocks.
Gtest is a framework for unit testing. Gmock is a framework imitating the rest of your system during unit tests.
Let say you want to write something to file.
You have to test like system memory is full or not.
Will you make the system memory full to test this? No.
Your friend Google mock will help you here.
"Google Mock is not a testing framework itself. Instead, it needs a testing framework for writing tests. Google Mock works seamlessly with Google Test. It comes with a copy of Google Test bundled. Starting with version 1.1.0, you can also use it with any C++ testing framework of your choice. " - Google Mock, System Requirements
Mock are like objects, defined in such a way to mimick the real-deal by supplying controlled behavior. For instance, to test a stock tick application, you'd create a fake stock data provider that created fake stock quotes to test your code with. Think of the word mock, literally means 'to mimic'.
Suppose you're writing a piece of code that needs to interact with an unpredictable, expensive, external system (e.g. a Web site, a large database, a physical sensor, etc.) Your code needs to keep working when the external system times out, or gives you error messages, or gives you inconsistent data. How can you test whether your code actually meets those requirements?
Well, you could run it against an actual Web site/database/sensor/whatever, a whole bunch of times, and hope you luck into all the error conditions that your code is supposed to handle. Obviously a fairly expensive and unreliable testing strategy.
So instead, you write something that satisfies the same interface as the Web site/database/sensor/whatever, but which you've programmed to produce certain "canned" responses (errors, timeouts, inconsistent data, etc.) Your tests will now run much faster (because they don't face the overhead of a real Web site/database/sensor/whatever), and they're predictable. Unfortunately, it takes a lot of coding to write up a separate "mock" Web site/database/sensor/whatever for each scenario you need to test. The more work it is, the less likely you are to do it. Result: inadequately tested code.
Gmock and its relatives automate a lot of this stuff, so you can specify the desired "canned" behavior in the middle of the test itself, at the cost of only a few lines of code. If tests are easy to write, you're likely to write more of them, and therefore more likely to discover bugs before shipping the code :-)
BTW, this implies that you also need "dependency injection": your code needs to take in a parameter of the interface type, and you need to be able to pass in either a mock object (for unit-testing) or the "real" Web site/database/sensor/whatever (for real-world use).