Victor
Victor

Reputation: 953

TFS Fakes Build Unit test failure

We have a VS2013 .net 5.0 Solution (VS2013 Premium) with all Unit tests passing fine locally but failing several tests when running in VS Test Loader by TFS Build with this or similar Exception: System.TypeLoadException: Could not load type 'System.Diagnostics.Fakes.ShimEventLog' from assembly 'System.4.0.0.0.Fakes, Version=4.0.0.0, Culture=neutral, PublicKeyToken=0ae41878053f6703'. This is an example of a failing test:

    [TestMethod]
    public void WriteToEventLogTest_HappyPath()
    {
        EventLogEntryType eTypeInfo = EventLogEntryType.Information;
        bool sourceExistCalled = false;
        bool writeEntrycalled = false;

        using (ShimsContext.Create())
        {
            ShimEventLog.SourceExistsString = s =>
            {
                sourceExistCalled = true;
                return true;
            };

            ShimEventLog.AllInstances.WriteEntryStringEventLogEntryType = (@this, str, et) =>
            {
                writeEntrycalled = true;
            };

            Logging.WriteToEventLog(IpAddress, eTypeInfo);
            Assert.IsTrue(sourceExistCalled, "SourceExist() not called");
            Assert.IsTrue(writeEntrycalled, "WriteEntry() not called");
        }
    }`

We using TFS 2013 update 5 running on Windows Server 2012 R2. Is there anything that can likely cause this problem? Should we update TFS to the latest which is Update 5 at the moment?

Upvotes: 7

Views: 1586

Answers (3)

Choco
Choco

Reputation: 1488

just has a similar issue when using Shims in multiple separate Unit test projects. Apparently the generated shims can overwrite each over or something like that.

Here's the instructions I followed to fix it: Scroll to the middle of this page: https://msdn.microsoft.com/en-us/library/hh708916.aspx

It's under the heading of optimise build times, but use it to fix your problem too.

Because such assemblies rarely change on your machine, you can reuse the generated Fakes assemblies in other projects. From your unit test projects, you can simply take a reference to the compiled Fakes assemblies that are placed under the FakesAssemblies in the project folder.

  • Create a new Class Library with the .NET runtime version matching your test projects. Let’s call it Fakes.Prebuild. Remove the class1.cs file from the project, not needed.

    Add reference to all the System and third-party assemblies you need Fakes for. and generate the fakes, edit the .fakes file if you like, and build to generate the fake assemblies.

    From your Unit Test projects Just make sure that you have a reference to the Fakes runtime DLL: C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.QualityTools.Testing.Fakes.dll

    Then for each assembly that you have created Fakes for, add a reference to the corresponding DLL file in the Fakes.Prebuild\FakesAssemblies folder of your project. (This folder get created when you compile)

    To confirm You will need to add the reference by Browsing to the generated fake assembly..

Upvotes: 0

AxiomEnvy
AxiomEnvy

Reputation: 11

In our situation, we were running several unit test DLLs through VSTest in Jenkins.

Example call:

"c:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" 
"./TestDLL1.UnitTests/bin/Debug/TestDLL1.UnitTests.dll" 
"./TestDLL2.UnitTests/bin/Debug/TestDLL2.UnitTests.dll" 
"./TestDLL3.UnitTests/bin/Debug/TestDLL3.UnitTests.dll" 
/Enablecodecoverage /UseVsixExtensions:false /Logger:trx

Some of the test projects had Fakes for the same DLL, with most setup to Fake everything. One test project was only faking one class, as the XML shows below, in order to prevent the warning about "Some fakes could not be generated."

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/" Diagnostic="true">
  <Assembly Name="Utilities"/>
  <StubGeneration>
    <Clear />
  </StubGeneration>
  <ShimGeneration>
    <Clear />
    <Add FullName="UIUtils.ExceptionDisplay"/>
  </ShimGeneration>
</Fakes>

For some reason, VSTest was using the above version for the other test projects. Modifying the one test project to generate all the fakes fixed the issue with System.TypeLoadException. We may consolidate our Fakes in the future, to be able to more easily limit which classes are faked, but for now this was a much quicker solution to the issue.

If only there was an easier way to suppress the "Some fakes could not be generated" warning...

Upvotes: 0

Victor
Victor

Reputation: 953

Problem was resolved by sharing fakes configuration files between the Test projects on a Solution level

Upvotes: 3

Related Questions