NMock3 Issue Tracker Rss Feed

Reopened Issue: MockStyle.Transparent not working as expected [10152]

pwolfe — Fri, 14 Jun 2013 07:22:58 GMT

When a Mock is created with mockStyle = MockStyle.Transparent, the underlying implementation is executed even when an Expect or Stub statement is used to override certain functions or properties. The return value of the function or property is correctly set according by the WillReturn() statement, so it appears that the underlying implementation is executed, and its return value discarded. Exceptions are not disregarded this way. In my case, they are being thrown to NUnit and resulting in failing tests.

Closed Issue: MockStyle.Transparent not working as expected [10152]

pwolfe — Thu, 16 May 2013 10:41:24 GMT

Created Issue: MockStyle.Transparent not working as expected [10152]

brianFaires — Tue, 08 May 2012 23:30:51 GMT

Closed Issue: Exception when using NMock3 - Beta 6, .NET 3.5 [6671]

pwolfe — Wed, 27 Jul 2011 20:28:11 GMT

Hi,

when I use the binary for .Net 3.5 I get the exception
"Type 'foo' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is attempting to implement an inaccessible interface"
The mocked interface is public an defined in the same assembly like the mock-call.

Compiled for .Net 4 with a reference to the .Net 4-mock-binary my little test works fine.

Regards,
Dirk
Comments:

Closing because of no response since 9/16/10. Suggest to try with current version.

Closed Issue: (Duplicate Please delete) Expects.Exactly(int) doesn't work as expected [8189]

pwolfe — Wed, 27 Jul 2011 20:17:02 GMT

I believe there is an issue with the Expects.Exactly(int) functionality. The code appears to check that the actual number of calls does not exceed the number of expected calls. Consider the following scenarios

Scenario 1:
Expect Exactly = 4
Actual = 4 passes as expected

Scenario 2:
Expect Exactly = 4
Actual = 5 fails as expected

scenario 3:
Expect Exactly = 4
Actual = 3 passes when it should faile
Comments:

duplicate

Commented Issue: Expects.Exactly(int) doesn't work as expected [8190]

pwolfe — Wed, 27 Jul 2011 20:16:30 GMT

I do not see this behavior. Can you please post a unit test that demostrates it? There are specific unit tests in the code base that are testing this functionality and they are passing. Thanks.

Created Issue: Expects.Exactly(int) doesn't work as expected [8190]

sgmeyer — Wed, 02 Mar 2011 18:23:25 GMT

Created Issue: Expects.Exactly(int) doesn't work as expected [8189]

sgmeyer — Wed, 02 Mar 2011 18:23:20 GMT

Commented Issue: Exception when using NMock3 - Beta 6, .NET 3.5 [6671]

pwolfe — Thu, 16 Sep 2010 18:19:05 GMT

Your setup seems right. Can you provide a code sample?

Created Issue: Exception when using NMock3 - Beta 6, .NET 3.5 [6671]

Bitbierchen — Thu, 08 Jul 2010 07:36:30 GMT

Closed Issue: Build event for NMock2 has invalid path [5203]

pwolfe — Wed, 13 Jan 2010 06:46:20 GMT

The path to the Castle.DynamicProxy2.dll is invalid. This causes a reference to the dll necessary when using NMock3.
Comments: Resolved with changeset 40296.

Closed Issue: Build number should be a manual update [5202]

pwolfe — Wed, 13 Jan 2010 06:46:20 GMT

The build number shouldn't be a .* but a manually incremented number.
Comments: Resolved with changeset 40296.

Closed Issue: Handling non-void return types from MethodWith [5201]

pwolfe — Wed, 13 Jan 2010 06:46:19 GMT

MethodWith can only handle void return types and classes that have default constructors because of a MessageGrabber limitation.
Comments: Resolved with changeset 40296.

Created Issue: Build event for NMock2 has invalid path [5203]

pwolfe — Wed, 13 Jan 2010 06:45:07 GMT

The path to the Castle.DynamicProxy2.dll is invalid. This causes a reference to the dll necessary when using NMock3.

Created Issue: Build number should be a manual update [5202]

pwolfe — Wed, 13 Jan 2010 06:43:56 GMT

The build number shouldn't be a .* but a manually incremented number.

Created Issue: Handling non-void return types from MethodWith [5201]

pwolfe — Wed, 13 Jan 2010 06:42:28 GMT

MethodWith can only handle void return types and classes that have default constructors because of a MessageGrabber limitation.