I am just starting with mocking using googlemock for a C++ project. In my case, my class to be tested observes a file that is written to, and whenever a minimal amount of new data has been written, it starts doing some work.
What I need is a mock class for the process writing to the file. As far as I understand things, I need to completely implement this "writing to file" functionality in form of (for googlemock) a virtual class from which a mock class is derived? The mock wrapper is finally used for testing and evaluation purposes, right?
Thanks for help!
Mocks, in google mock terms, are objects used to validate that your code under test performs certain operations on them.
What you describe is not a mock, but a utility class that triggers your code under test operations.
What does your class do when it detects that the file it observes is written to? If, for instance, it performs a call to another object, then you could use a mock object to check that it gets called with the right parameters, e.g. the new bulk of data written to the file.
I am assuming that an object of your "observer" class is notified
that minimal amount of data has been written by an object of
the "writter" class. In that case, you need to implement an abstract
class that represents an interface for your "writter" class, and have
your real "writter" class inherit from it and override its virtual functions.
Also, have your mock "writter" class implementation inherit from this interface and
and create mock implementations using MOCK_METHODn.
Then, have your "observer" class receive notifications from "writter" object
using a pointer to the abstract class. This way, you can use dependency
injection to switch implementation during testing phase by creating a mock
"writter" object and passing its address to "observer" object (instead of an address to a real "writter"
object) and setup test cases using EXPECT_CALL on the mock object.
This is the best advice I can give since you did not provide us with a detailed description of your classes.
EDIT:
Concerning the implementation of your real "writter" class: You do not have to create it immediately, you can use the mock class for now to test the behavior of the "observer" class and leave the implementation for later. You will, of course, have to implement it eventually since it has to be used in production code.
Related
In the TDD there is two concept: fake objects and mock objects. These two concepts are used in case a class you want to test is interacting with other classes or objects or databases...
My question is : what is the difference between the two? and when can I use each one of them?
Edit:
I found this answer:
What's the difference between faking, mocking, and stubbing?
But I'm still confused about the difference between the two:
both of them create implementation of the components, with light implementation for a Fake. But, what do they mean by "light implementation" of "shortcut" in case of a fake?
And what is the difference between how a Mock object works, and the real object work?
A fake implementation for a DataSet for instance, would simply return a static set of data. A mock would pretty much be a full implementation that would be able to generate various sets of data depending upon input. If you were mocking away your data layer, you would be able to execute your command objects against the mock and it would be robust enough to return data with a "valid" statement, or throw exceptions with an invalid statement. All without actually connecting to a database or file.
As for the differences between mock and real, usually when mocking a class away, you would create a factory object that, by default, returns the real object, but when you write your tests, you can tell it to return a specific mock class. The mock class either implements the same interfaces as the real object, or you use a wrapper class that mimics the underlying real class, but allows for dependency injection for the critical parts to generate data without making the external calls.
This might be a noob question however, I am not entirely sure on the procedures to writing unit tests for an abstract class in Salesforce. The class itself has 3 public methods as well as two abstract unimplemented methods. I unfortunately haven't found much help on the topic.
I know abstract classes cannot be constructed which means I can't create an instance of it to test on. Greatly appreciate any inputs.
What ultimately worked for me was, I used a class that was already extending the abstract class to call the methods I needed to test. I didn't need a mock object or to create a whole new sub-class to test.
You could create a test subclass which would implement those abstract methods with dummy implementation.
That way, you can instantiate this test class in your test: calling its non-abstract methods will run the production code.
Alternatively, you could look into mocking frameworks: they might even remove the need to subclass the class yourself.
If you have a class called MyClass with a set of public methods; MethodA, MethodB and MethodC. And in some locations of an application you only need a single method from MyClass, for example:
MyClass myClass = new MyClass();
myClass.MethodA();
To simplify the above I would like to create a single static method that wraps the above lines of coded. I am planning to write unit tests against MethodA. In my unit test MethodA interacts with an interface that is implemented using a mock framework (I think this is called Inversion of Control).
Is it safe to assume that by testing MethodA that the static method (wrapper method) is also being tested indirectly. I am assuming the actually implementation for the interface used in MethodA is also being tested.
Or should I not implemented the static method?
Please, don't do that!
Static methods used like you want to do are the exact opposite of inversion of control / dependency injection, and as such, are a bad practice.
What you want to do is inject into all classes that need a MyClass an interface to it (either injected through the constructor or a setter, manually or using a IoC framework like Spring).
If you wrap your lines of code in a static method that you call from another class, then you'll couple the specific implementation of MyClass too tightly, which is the opposite of what you want to achieve.
But to answer your more specific question, it's never safe to assume the code is tested by another test, unless it actually is. What I mean is: if there is NO test that go through the static method, then it's not covered. Even if you may think it's trivial, don't forget it may be refactored later, and no test will indicate it's broken.
No, it's not safe to assume the wrapper method is also being tested. There is code in the wrapper method, and that code could have a defect in it, so you'll need to write unit tests against that code as well.
I am using Google Mock 1.6 RC and am trying to Mock a COM Interface. There are close to 50 methods in the COM Interface some of which are inherited from base interfaces. When I create a mock struct that inherits from this interface and mock only the methods I am using, I get the cannot instantiate abstract class error.
I want to know if it is possible to do this in googlemock or not.
It is not possible to do. You have to overload all pure virtual methods from all interfaces (except for the constructor and destructor).
You have to override every method that has been declared as pure virtual in the classes you inherit from, directly or indirectly. There are two reasons not to want override them all:
There are too many of them and you have something better to do with your time than to go over them all.
Compiling a mock class with all of them mocked out is too slow and takes too much memory.
The fix for (1) is to use the gmock_gen.py script in Google Mock's scripts directory. It goes over the class definition and converts method declarations into the MOCK_METHOD statements. If you have problems with (2), you can replace the unnecessary MOCK_METHOD statements with stubs:
MOCK_METHOD1(f, bool(int i));
with
virtual bool f(int i) {
thrown std::exception("The stub for f(int) has been invoked unexpectedly.");
}
Throwing an exception will alert you to a situation where a particular stub has been invoked, meaning you likely need to mock it instead.
Edit: If the original interfaces to mock are written using Microsoft's macros, this thread has a script posted that converts them to C++ acceptable to gmock_gen.py.
I'm not entirely sure whether all methods should be covered in the mock class... In the gmock examples you can see that for example destructors are not mocked. Therefore I presume there is no need to mock the entire class.
Anyway, shouldn't you create mock class rather than mock struct?
However, there is a gmock_gen.py tool in scripts/generator that should do the hard work of mocking large classes for you.
I'm just getting into Test Driven Development with mock objects. I can do it the long way with UnitTest++, but now I want to try to minimize typing, and I'm trying to use AMOP mock framework to do the mocking.
AMOP states:
The main differences between AMOP and other mock object library is that,
users DO NOT need to implement the
interface of the object which to
mock...
However, I can't figure this out. The basic usage page still shows a IInterface class. Anyone able to do it without using an interface class?
For what I've seen in the documentation, it actually doesn't need the mock object to implement any interface. The mocking object is constructed based on the original object's interface, but not by inheritance, but as a parameter of the class:
TMockObject<IInterface> mock;
No inheritance here, and TMockObject doesn't get tied to any interface by inheritance. Then, adding mock methods to be implemented by the mock object:
mock.Method(&IInterface::SimpleFunction);
mock.Method(&IInterface::SimpleFunctionWithAlotParams);
((IInterface*)mock)->SimpleFunction();
((IInterface*)mock)->SimpleFunctionWithAlotParams(0, 0, 0, 0, std::string());
Again, the object mock does not actually inherit the interface. It may redefine the conversion operator to IInterface* (it will return an internal IInterface object).
I don't see many advantages in not inheriting the interface, but anyway. I would have preferred some template as member function of TMockObject to give more meaning to that ugly cast (not tested, just an idea):
template <typename I>
I* as(void)
{
return m.internal_interface_pointer_;
}
so you could write something like:
mock.as<IInterface>()->SimpleFunction();
but still...
This is the first time I hear that a mock framework doesn't need an interface to crate mock objects. Every other do. Must be a bug in the documentation.