New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide better error reporting in Verify() #84
Comments
I think that for objects you have a nice workaround most of the times, which is to override Also interesting for enhancing reporting is when you have array parameters, which is specially useful for |
I think this idea has a lot of potential. But I don't think it would be good to decide on one fixed way of reporting additional object data, because of the problems this could cause (see @icalvo's post above). I would suggest that this new functionality be exposed in a slightly more general way. For example, a new public contract could be introduced, say: namespace Moq.Diagnostics
{
public interface IObjectFormatter
{
string Format(object obj);
}
} Exactly one instance of this new interface type could then be registered on a By default, Moq would be using a If the questions raised in the post above can be solved such that the resulting formatting would work well for most objects, Moq could ship with one (or several) additional concrete implementations in the new |
Closing this issue due to inactivity. It also belatedly occurred to me that it wouldn't be straightforward to figure out when to use an object's |
Well, an easy workaround would be to ignore all But even if we don't, that would just provide some extra information for those:
|
This would be super valuable... with BDD-style testing, I often have to use Example: _context.MailNotifier.Verify(
x => x.SendNotification(It.Is<NotificationViewModel>(n =>
n.Username == currentUser.Username &&
n.IsOptional)), Times.Once); Either expression could be false and I won't know which. This is a simple example, when I do things like "StartsWith(str)" it becomes even more annoying to figure out why it failed. I mention BDD-style specifically what I wantWhat I want is what I can do in Jest projects (pseudo code equivalent of above): expect(_context.mailNotifier.sendNotification).toHaveBeenCalledWith(expect.objectContaining({
username: currentUser.username,
isOptional: true
}); When this expectation fails, Jest gives me a full diff of the properties I was comparing. Perhaps for Moq, another similar API could allow the same thing? _context.MailNotifier.Verify(
x => x.SendNotification(It.IsObjectContaining<NotificationViewModel>()
.Where(n => n.Username, Is.EqualTo(currentUser.Username)
.Where(n => n.IsOptional, Is.True)
)
), Times.Once); This has the added benefit of reusing existing |
Example of reporting I get in 4.1.1311.615:
Reporting that would be more useful:
As for the second point, I have done similar thing once -- can be done by finding all distinct property/method paths in expression tree passed to
It.Is
and requesting their values for actual argument.The text was updated successfully, but these errors were encountered: