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
0 votes
I'm using TypeMock 3.7.1.0 on .NET 1.1.

It seems that when I set up an expect-and-return using Natural Mocks on a static method, the first time I try setting up the expectations it's actually calling the static method, which is causing my tests to fail in odd and unfortunate manners.

For example, in my test [SetUp] I might have something like:

SomeObject returnValue = new SomeObject();
using(RecordExpectations recorder = RecorderManager.StartRecording())
{
  recorder.ExpectAndReturn(ServiceClass.GetSomeValue(), returnValue);
  recorder.RepeatAlways();
}


And the ServiceClass might look like this:

public sealed class ServiceClass
{
  private static readonly LoggingClass logger = LoggingClassFactory.GetLogger();

  public static SomeObject GetSomeValue()
  {
    logger.Log("Going to return a value now.");
    return new SomeObject();
  }
}


If I execute a test, the test will fail because when I'm setting up expectations, the GetSomeValue method will actually execute, the "logger" static variable won't be initialized, and I'll get a NullReferenceException.

Interestingly enough, this will only happen for the first test that executes - on subsequent tests, this passes (but ostensibly because the static "logger" has been initialized).

Unfortunately I tried to put together a simple reproduction but I don't seem to be able to reproduce it outside of the [actually fairly large] project I'm working in.

I have many, many other tests using TypeMock and this is the only instance I'm seeing this issue, and it's only when mocking statics.

I've had other developers try it and it's failing on other machines, including our build server, so it's not environmental.

We do have a fairly complex series of dependencies with this project and have several strong-named references that are getting worked out at runtime using app.config files with bindingRedirects specified. I don't know if this affects how TypeMock might deterine what to mock, but this seemed pretty special-case to me, which might be why I can't put together a separate reproduction.

These tests worked with no issues under TypeMock 3.6.0.0. I only encountered it when I upgraded to 3.7.1.0. I don't know if there's some difference in how statics are handled between the two.

Unfortunately, if I can't get this resolved reasonably soon, I'm going to have to revert back to 3.6.0.0, which isn't something I want to do.

Let me know if I can answer any additional questions or try anything out to help diagnose.
asked by tillig (6.7k points)

5 Answers

0 votes
Minor update/additional info - it's happening in more than one project, on more than just this set of unit tests, so it's not just this one project or something odd that might be happening in that one unit test assembly. Different projects, different unit test assemblies, different runs of NUnit, but the same code.
answered by tillig (6.7k points)
0 votes
Hi,
This is quite strange as we have the same tests and it runs correctly.
Could you tell us:
1. How you are running the tests (Nant,msbuild,tmockrunner,TestDriven)?
2. Is the test and the ServiceClass in the same assembly?
3. Could you run with Logging enabled send the log to our support e-mail?
4. Run the tracer before your test, then run the test, export the trace and send it as well
answered by scott (32k points)
0 votes
I thought it was strange as well. :)

I am running the tests in several ways - via NAnt in a call to NUnitConsole.exe as well as through TestDriven.NET "Test In Debugger." The tests fail at the same point with the same message in each, so it doesn't seem to hinge on the mechanism through which I'm testing.

The test is not in the same assembly as the ServiceClass. Actually, my example may be a little over-simplified since:
  • The thing that I'm testing makes use of ServiceClass, it's not the ServiceClass proper.
  • In other code in the test assembly we do make use of ServiceClass directly, but a newer version of ServiceClass than the version used by the thing I'm testing, and the ServiceClass assembly is strong-named, hence my mention that we have a pretty complex series of dependencies.
  • This binding-and-redirection thing, when I diagrammed it out, runs about five levels deep.


...which is why I wasn't really able to come up with a reproduction. Even in the fairly complex reproduction I made (which went about three levels deep with different versions of a strongly-named assembly and all the bindingRedirects and such), I wasn't able to get the failure I'm seeing here.

I will put together the two pieces of evidence you've requested and send them along. Thanks!
answered by tillig (6.7k points)
0 votes
Thanks for sending the logs and the demo code, this really helped.

What is happening is that the first time the method is called the AspNetHostingPermission security attribute is kicked in.

We have a defect :twisted: and we don’t handle this correctly.
Because this happens the first time the method is called, the recording fails the first time.

:idea: We will fix this and send a patch.
answered by scott (32k points)
0 votes
Hi
The fix is available to all in 4.0.0 release
answered by ohad (35.5k points)
...