What steps will reproduce the problem?
var x = new Mock<X>();
x .Setup() .Verifiable();
// Lots of code
x.Verify();
What do you want to see instead?
using (x = new Mock<X>()) { x .Setup() .Verifiable();
// Lots of code
}
What version of the product are you using? On what operating system?
Moq 4.0.812.4 W7RC VS2K8
Comment #1
Posted on Nov 12, 2009 by Helpful GiraffeHave a temp workaround:-
public static class MockExtensions
{
public IDisposable Verifier( this Mock mock )
{
return new UndoSetupAction( ( ) => mock.Verify( ) );
}
}
public class UndoSetupAction : IDisposable
{
public delegate void RollbackActionDelegate();
private RollbackActionDelegate _action;
public UndoSetupAction( RollbackActionDelegate action )
{
_action = action;
}
void IDisposable.Dispose()
{
_action();
_action = null;
}
}
Hence I can now write:
x = new Mock(); using (x.Verifier()) { x .Setup() .Verifiable();
// Lots of code
}
Comment #2
Posted on Nov 12, 2009 by Happy RabbitWe have decided long ago that this leads to imposible to reuse mocks, as well as too coarse-grained error messages as you then have to figure out which of a number of mocks failed (using a mock repository, as nested usings on multiple mocks also gets very cumbersome very quickly).
And many users reported this being ugly in Rhino too.
Once you switch to the AAA style of mocking (calling Verify(expression) instead of using Verifiable() setups), you'll see that this makes little sense.
Comment #3
Posted on Nov 13, 2009 by Helpful GiraffeDoh!
Thanks for the correction. Have recoded usages of this approach and they're much clearer, thanks.
Any chance of there being a Core vs Ext split and/or approach a la xUnit.net with an agressive trimming of the Core, possibly via extension classes to make Verifiable () 'Obsolete' ? Maybe something like http://briannoyes.net/2009/11/04/UseExtensionMethodsToPhaseOutABadAPI.aspx ?
Status: WontFix
Labels:
Type-Defect
Priority-Medium