StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
5601992
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2011-04-09T00:11:53.713
FavoriteCount
0
LastActivityDate
2011-04-09T00:11:53.713
LastEditDate
LastEditorUserId
0
OwnerUserId
1219618
ParentId
5519620
PostTypeId
2
Score
3
ViewCount
0
LastEditorDisplayName
text
Body
Ultimately, your question is whether a mocking framework should take snapshots of the parameters you use when interacting with the mocks so that it can accurately record the state the system was in at the point of interaction rather than the state the parameters might be in at the point of verification. I would say this is a reasonable expectation from a logical point of view. You are performing action X with value Y. If you ask the mock "Did I perform action X with value Y", you expect it to say "Yes" regardless of the current state of the system. To summarize the problem you are running into: <hr> <ul> <li>You first invoke a method on a mock object with a reference type parameter.</li> <li>Moq saves information about the invocation along with the reference type parameter passed in.</li> <li>You then ask Moq if the method was called one time with an object equal to the reference you passed in.</li> <li>Moq checks its history for a call to that method with a parameter that matches the supplied parameter and answers yes.</li> <li>You then modify the object that you passed as the parameter to the method call on the mock.</li> <li>The memory space of the reference Moq is holding in its history changes to the new value.</li> <li>You then ask Moq if the method was called one time with an object that isn't equal to the reference its holding.</li> <li>Mock checks its history for a call to that method with a parameter that matches the supplied parameter and reports no.</li> </ul> <hr> To attempt to answer your specific questions: <ol> <li>Is this expected behavior? I would say no. </li> <li>Is this new behavior? I don't know, but it's doubtful the project would have at one time had behavior that facilitated this and was later modified to only allow the simple scenario of only verifying a single usage per mock.</li> <li>Is there a workaround that I am unaware of? I'll answer this two ways. From a technical standpoint, a workaround would be to use a Test Spy rather than a Mock. By using a Test Spy, you can record the values passed and use your own strategy for remembering the state, such as doing a deep clone, serializing the object, or just storing the specific values you care about to be compared against later. From a testing standpoint, I would recommend that you follow the principle <a href="http://xunitpatterns.com/Principles%20of%20Test%20Automation.html" rel="nofollow">"Use The Front Door First"</a>. I believe there is a time for state-based testing as well as interaction-based testing, but you should try to avoid coupling yourself to the implementation details unless the interaction is an important part of the scenario. In some cases, the scenario you are interested in will be primarily about interaction ("Transfer funds between accounts"), but in other cases all you really care about is getting the correct result ("Withdraw $10"). In the case of the specification for your controller, this seems to fall into the query category, not the command category. You don't really care how it gets the results you want as long as they are correct. Therefore, I would recommend using state-based testing in this case. If another specification concerns issuing a command against the system, there may still end up being a front door solution which you should consider using first, but it may be necessary or important to do interaction based testing. Just my thoughts though.</li> <li>Am I using Verify incorrectly? You are using the Verify() method correctly, it just doesn't support the scenario you are using it for.</li> <li>Is there a better way of using Moq to avoid this situation? I don't think Moq is currently implemented to handle this scenario.</li> </ol> Hope this helps, Derek Greer <a href="http://derekgreer.lostechies.com" rel="nofollow">http://derekgreer.lostechies.com</a> <a href="http://aspiringcraftsman.com" rel="nofollow">http://aspiringcraftsman.com</a> <a href="http://twitter.com/derekgreer" rel="nofollow">@derekgreer</a>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POUnexpected Validate behavior with Moq
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USDerek Greer
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POUnexpected Validate behavior with Moq
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. CODerek - Thanks for your response. I definitely agree with your conclusions. I actually ended up changing the code under test a while after posting this. The changes resulted in another variable being created after the initial call to the database mock, which alleviated the problem I describe above. In the back of my mind, I still think of this as a 'rookie' misunderstanding of passing objects by value vs. reference. It's nice to see that someone else agrees that my expectations of the verify behavior are reasonable.
 singulars
 PostPostId
 PO
 UserUserId
 USAwesomeYetIronicPseudonym

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.