|
From: <thi...@gm...> - 2004-10-14 09:01:56
|
Hi gentlemen,
I'm really new to mock objects, apart from very basic stuff, and would
like to have your opinion about the way I plan to use them.
I am testing interaction with remote servers, and I'm expecting to be
called in one of several callbacks (registered to the server) in my
testfixture to decide that my test has passed. Callbacks, if called,
set an AutoResetEvent. I'm currently testing the behaviour using this
:
AutoResetEvent _connected = new AutoResetEvent(false);
/// <summary>
/// Callback for connect test
/// </summary>
/// <param name="e"></param>
private void Connected(object sender,ConnectionEventArgs e)
{
// mark the event
_connected.Set();
}
....
WaitHandle[] handles = { _accepted,_rejected,_cancelled };
Assert.IsTrue(WaitHandle.WaitAny(handles,5000,true)!=WaitHandle.WaitTimeout,"No
valid callback called.");
I'm thinking about refactoring the callbacks and waitany code inside a
mock object, with some "expectations" that would do what I need. I
would then mock the receiver, not the server.
To give more background, the remote servers (~ 10 different
implementations, native c++ code) are wrapped behind a common managed
c++ proxy interface. I couldn't manage to see the benefits of just
mocking one of the remote server, as it would not test the real thing.
What do you think of mocking the receiver ? Could I do better here ?
Am I totally wrong somewhere ?
thanks in advance
Thibaut
|