1.31b doesn't execute MSpec tests

Hi,

first of all thanks doing such great work.

Version 1.30b worked quite well for me but after updating to 1.31b this morning my MSpec tests don't execute any longer.

When clicking on a row "Run 5 Tests" in the Processing Queue it shows the following exception in the details box below:

[08:26:22.7828-TestExecutionTask-43] Error 'Internal': System.TypeLoadException: Could not load type 'Castle.Core.Interceptor.IInterceptor' from assembly 'Castle.Core, Version=2.5.1.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.
at nCrunch.TestExecution.Frameworks.MSpec.MSpecTestFramework.#=qkZtigWnrFzrHjbmdz$TZHz9Jc2gcXdnxFbc$1d$77_U=.#=qw9VJtnyDYdsBYpFJWZ1xuQ==()
at #=qZfBi_VMr$9hYvCPxGnLkD5xFW0OSKSeBdU8BPxPUv5Ojf3rSdy7kw922DNNXry2t.#=quTMn4iDd$Fc_VoPTDz$iRqhyrKGu_gwbp7yrWCpNETs=(Action #=qi4uFd$JRapiS$ymC$WXirHGT6b097YlYfj72f8bBZUA=)
at nCrunch.TestExecution.Frameworks.MSpec.MSpecTestFramework.RunTests(TestOutput output, IList`1 testsToRun, MasterExecutionMapSet masterMapSet)
at nCrunch.TestExecution.TestRunnerThread.#=q5qAH8o1SN7xgq9ABN7XSIA==(IMasterExecutionMap[] #=qzqPXZoA$nSnZ7LqmRccxUclO$MwwnyD1HYX6LCXOAm4=, IList`1 #=q4dJfWSbgrHs7Mw_ByN7ruA==)

I'm running VS 2010 Ultimate EN on Windows 7 EN x64.

Alex

Hi Alex - Thanks for posting this so promptly.

Are you using the Castle.Core assembly inside your project? I'm wondering if this could be a clash between a version of Castle used by your project vs. the version used by NCrunch's MSpec runner.

I'm curious (and a bit concerned) as to why this would suddenly appear in 1.31b ... if you uninstall and downgrade back to 1.30b, do the tests run ok?

Hi Remco,

thanks for your fast reply.

Indeed I'm using Castle.Core inside my project due to using NHibernate inside this project.

Just downgraded to 1.30b and everything is ok.

Alex

Hi Remco,

same problem here. I'm using MSpec with Machine.Fakes with FakeItEasy. Castle.Core 2.5.1 is referenced by the project (I installed MSpec and MSpec.Fakes with nuget).


Regards
Stefan Lieser

Same here (with Machine.Fakes.FakeItEasy).

Also the coverage is wrong. It shows good Test. But not real running them.

Image http://twitpic.com/528p9g/full

Me, too

Can each of you guys punch through a bug report after you get the run failure?

Also ... are any of you working in an open source codebase? If I have access to a solution that surfaces the problem consistently, I should be able to fix it quite promptly :)

I tested it with this project https://github.com/Slesa/Playground/tree/master/src/Lucifer this morning. Beside the mentioned effect of using Castle.Core, there is an error within Lucifer.Editor, where it does not find the assembly of Caliburn.Micro. That's what I sent a report about.

Excellent - thank you :) I'll take a look.

I've taken a good look at this and reproduced both issues in the Lucifer solution:

1. As described, MSpec blows up when using the latest version of Castle in the testing environment. I've introduced a fix for this in the upcoming 1.32b release.

2. The Caliburn.Micro build issue appears to be triggered by a namespace clash issue where MSBuild cannot tell the difference between two different namespaces referenced within one of the source files. The cause of this issue is that NCrunch is erroneously including an entire dependency tree of assembly references when building the project, where it should only be including assemblies referenced directly from the project being built. I've fixed this issue in the upcoming 1.32b release. Meanwhile, a workaround could be to try rearranging some of the namespacing around this error. You should easily be able to reproduce the problem outside of NCrunch if you introduce a project reference from Lucifer.Caliburn from Lucifer.Editor.

Thanks again for providing the source. This made fixing the above issues much easier :)

For anyone interested, a proper fix for both of the above issues has now been released as part of 1.32b.

Confirmed! Thanks.

Hate to pull up an old topic, but the history on this one matched so well.

I'm a new user of 1.32b and my mspec tests are showing up in the runner; however, they are always passing.

Code example:

[Subject("a failure")]
public class a_when_doing_something_wrong
{
  It should_fail = () => "moo".ShouldEqual(2.ToString());
}

The test, however, passes in the runner. It properly fails when executing it from mspec:

Machine.Specifications.SpecificationException: Should equal "2" but is "moo"

I've tried this at various nesting levels, with and without a because/context, and still nothing. I also do not appear to have any code coverage; however, the .pdb files are available.

This forum thread leads me that this is fixed, but is there a configuration setting I'm missing?

Thanks!

-dl

Thanks for reporting this issue.

This definitely looks like a new problem, and it's definitely not the intended behaviour.

Do you notice this for ALL the tests in your entire solution? Do they by chance still fail if you explicitly throw an exception from one of them?

Also ... is the missing code coverage universal or does it only apply to a specific project? Do you still see black markers where the coverage is missing?

@Remco-

1) Yes, this was for all tests in the solution. I tried it on a few different solutions of varying size (ranging from ~30 tests to 800 tests). If I explicitly throw an exception, it still passes. That is what originally clued me into the problem. I assumed mspec's Catch.Exception was broken on my last build.

2) The code coverage (or lack thereof) seems universal. I verified that the .pdb files exist and, I'm assuming, are accessible. The black markers are appearing on all projects in the solutions.

I've tried in x64, x86, DEBUG, RELEASE, and combinations of each for build configurations. so far no luck.

Thanks!

Something is definitely going very wrong in there ... Would you mind kicking through a bug report if you haven't already? I have a feeling that something in your solution is causing a failure.

Submitted a bug report; thanks!

Excellent thank you!

For anyone interested, this issue should be fixed in the recently released 1.33b.