chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.
0 votes
While some may argue that this is getting to detailed in a test, from my stand point, where many tests are more insurance against others changing things and not realizing the impact, I might have part of my assert check that the stored procedure in a 'case' statement I'm testing is what I expect to be called:

Isolate.Verify.NonPublic.Property.WasCalledSet(fakeCmd, "CommandText").WithArgument("spName");


Now it would seem to me, that because CommandText is actually a public property of IDbCommand that it should be pretty straight-forward to support a feature that allows the following:

Isolate.Verify.Property.WasCalledSet<SqlCommand>(() => fakeCmd.CommandText).WithArgument("spName");


This will in cases where it's a more 'custom' property, to have type checking and easier refactoring. Obviously the original method needs to be kept for non-public properties.

Here's an example of the code that I would be testing against:

private void DataPortal_Fetch(Criteria criteria)
{
    string cmdText = null;
    switch(criteria.FetchType)
    {
         case FetchType.ActiveOnly:
             cmdText = "FetchActive";
             break;
         case FetchType.DeactivatedOnly:
             cmdText = "FetchDeactivated";
             break;
         default:
              cmdText = "FetchAll";
              break;
     }

     //Remainder of DataPortal_Fetch code which goes out to
    //database and makes the cmd.ExecuteReader call.
}
asked by boo (21.8k points)

3 Answers

0 votes
Hi Boo,

The syntax you propose is indeed comfortable, but this should be supported with our existing verification API:

Isolate.Verify.WasCalledWithExactArguments(() => {fakeCmd.CommandText = "spName";});

(The extra braces are there to help the compiler understand this is a property get rather than set).

Please let me know if this works for you and covers the scenario you describe.

Thanks,
Doron
Typemock Support
answered by doron (16.5k points)
0 votes
It probably will (Visual Studio is giving me OutOfMemory exceptions right now and takes 20 minutes to close and re-open).

Anyway, maybe this can be an alternative syntax in the future? The syntax there could lead some down the road of:

Isolate.Verify.WasCalledWithExactArguments(() => { fakeCmd.CommandText = "spName"; fakeCmd.CommandType = CommandType.StoredProcedure; });


And doing multiple checks like that might not be what you have intended the syntax for?

Of if it is - that's good to know about. Either way, something a little more intuitive might help.
answered by boo (21.8k points)
0 votes
I think the multiple checks you describe below (which are not supported) are pretty nice, but we haven't decided this way or that.

One guideline we have when designing our API is to keep intellisense clutter to a minimum, meaning we avoid new methods when possible. We will need to weigh the value add from your suggestion regarding adding specific handling for properties, vs. this clutter. Thank you for the suggestions, it's invaluable to get another angle on the subject.

Thanks!
Doron
Typemock Support
answered by doron (16.5k points)
...