Hi,
I have quoted from new thread:
(sorry, forgot to click notify me when a reply is posted). I would love to help add code on this feature!!!!
Here are some examples in Java
http://mockobject.sourceforge.net/
Basically, there is no Init, there is not verify. Instead, there is just code like this
CalledMethod m = mockObj.expectCall("method");
assertTrue("values should be same", true, m.getParameters()[0]);
assertTrue("values should be same", 5, m.getParameters()[1]);
The expectCall blocks for a period of "timeout" which is configured by the user. The default is 10 seconds and I have never overridden it myself. Realize the return values can't be specified in the expectCall as the method may be called before or after my call to expectCall, so instead there are methods to add return values and add throwing exceptions. It is quite nice not needing a verify or init. This allows one to get rid of it.
thanks,
dean
Thanks for the pointers, this looks very interesting, but there are a few differences in the frameworks.
:arrow: TypeMock mocks REAL concrete classes and not only interfaces.
:arrow: We require
Init() to be called for two reasons. The first is to start the insertion system, and the second is to
clear all return values of previous tests, so if a test fails, we don't fail the whole suite. This can happen in the proposed framework
:arrow:
Verify() is actually used to validate that all
expected calls were made, so if we expect that "method" should be called twice, but it was called only once, we can fail the test (You don't have to call Verify(), but I recommend it). This is something that cannot be done with the shown framework
:idea: You could implement this using the call event feature or using the dynamic return value delegate , although you will still have to write your expectations before the calling method, and the validations will be in another method, which can make things a little hard to understand
:?: Perhaps adding the following API's to the mock can help:
// save arguments for all calls
mock.SaveArguments = true
// get the arguments sent to method when called the <callNumber> time
mock.SentArguments("method",callNumber)
Then we our test will look like this:
[Test]
public void OurTest()
{
Authentication authenticator = new Authentication();
MockManager.Init ();
// the Logger class is now being mocked
Mock logMock = MockManager.Mock(typeof(Logger));
// save all arguments
logMock.SaveArguments = true;
// run test
authenticator.IsAuthenticated("user","password");
// Validate arguments sent to Log the first time
Assert.AreEqual(true,logMock.SentArguments("Log",1)[0]);
Assert.AreEqual(5,logMock.SentArguments("Log",1)[1]);
// we don't really need to test if Log was actually called
// because test will fail on previous line if Log wasn't called
//MockManager.Verify();
}
But adding this might confuse developers, as they will have too many choises to validate the calls.
Of course it seems easier to do the following: (Notice the
Args())
[Test]
public void OurTest()
{
Authentication authenticator = new Authentication();
MockManager.Init ();
// the Logger class is now being mocked
Mock logMock = MockManager.Mock(typeof(Logger));
// set up our expectations
logMock.ExpectCall("Log").Args(true,5);
// run test
authenticator.IsAuthenticated("user","password");
// make sure Log was actually called
MockManager.Verify();
}
About the timeout, we could probrably add a
mock.Timeout = timeout;
What do you think?