[Dotnetmock-users] MockCommand returning OUTPUT (db) parameters ?

[Chu V. <vin...@ax...>]

Hi all,

I am currently using MockCommand and MockDbConnection to test a
component that expects some values to be returned from a stored
procedure call.  The problem I am facing here is that when
MockCommand.ExecuteNonQuery() is called, there's no way for me to setup
mock result values and any code that expects return values from the
stored procedure call will fail.

I wish to have MockCommand setup the output parameter values when
ExecuteNonQuery() or ExecuteScalar() are called.  Here's an example in
the ideal situation:

// My test code
public void TestFindStatus()
{ 
	MockCommand cmd = new MockCommand();
	cmd.SetExpectedParameter(new MockDataParameter("StatusCode",
ParameterDirection.Output, 0));
	cmd.SetExpectedParameter(new MockDataParameter("StatusText",
ParameterDirection.Output, "ok"));
	Assert.IsTrue(FindStatus(cmd));
}


// My production code
public bool FindStatus(IDbCommand cmd)
{
	cmd.ExecuteNonQuery();
	if ((cmd.Parameters["StatusCode"].Value == 0) &&
(cmd.Parameters["StatusText"].Value == "ok"))
		return true;
	return false;
}

Two things to note here:
1.  MockDataParameter allows me to specify a parameter direction.
2.  When MockCommand.ExecuteNonQuery() is called, it should check the
actual parameters (_parameters._actualCollection) for output parameters.
If such parameters exist, then check the expected parameters for matches
and populate the actual parameter values accordingly.

Since MockCommand's job is to pretend that a command has been executed
(ExecuteNonQuery, ExecuteScalar), any expected output parameter value
should be copied to actual parameter's value.  As a bonus, MockCommand
can have a method SetExpectedBehavior() which takes a delegate and calls
that delegate when ExecuteNonQuery() etc are called.  This allows us to
mock database stored procedures easily when we are really interested in
testing the behavior of code that relies on the results of the database
SPs.  In fact, if SetExpectedBehavior() is implemented as a feature, it
could setup the actual parameter values when triggered.

Am I making sense ?  Barking up the wrong tree ?  Maybe there's a better
way of approaching this kind of test ?
If what I propose is reasonable, I'll post a RFE.  I've studied
MockCommand.cs and other sources carefully and can even perform the
change myself if the authors don't mind :)

Thanks for reading,
Vincent Chu