Nested test fixtures showing with red strike-through in Resharper Test explorer

[GoogleCodeExporter]

Just upgraded to R# 4.5 final with Gallio 3.0.6 Update 1, and I've 
discovered an issue with nested test classes.

If I have classes arranged like this:

class WidgetTests {

   class When_Widget_is_in_this_state {

      [Test]
      public void ThisShouldBeTrue() {
      ...
      }
   }
}

In the Resharper test explorer, all the nested classes and their tests are 
showing up with a red strike-through. When I run the tests their status 
bubble remains gray. Also, these tests are not being included in the test 
count.

However, opening the Gallio test report shows that the tests are being run 
correctly.

Note that any test methods included in the root of Widget tests are showing 
up correctly.

Original issue reported on code.google.com by samuel.j...@gmail.com on 9 Apr 2009 at 9:58

[GoogleCodeExporter]

I'll take a look this weekend.

Original comment by jeff.br...@gmail.com on 9 Apr 2009 at 7:40

• Changed state: Accepted
• Added labels: Component-ResharperRunner, Milestone-3.0.6, Priority-High

[GoogleCodeExporter]

When I punched in your example, I noticed that we did not detect the nested 
class as
a test class because it is non-public whereas it should have worked.  That 
problem is
now fixed.

Still trying to reproduce the red strike-through issue.  I saw something 
similar on a
different machine but it had nothing to do with nested classes.

Original comment by jeff.br...@gmail.com on 28 Apr 2009 at 4:44

[GoogleCodeExporter]

Issue 432 has been merged into this issue.

Original comment by jeff.br...@gmail.com on 28 Apr 2009 at 6:44

[GoogleCodeExporter]

Jeff,
  I've managed to isolate this bug, and find a work-around!

Turns out, in my original statement of the problem, I missed out the critical 
bit of information! Our nested 
test-classes all inherit from a base class that looks like this:

    [TestFixture]
    public abstract class ActOnceContextSpecification
    {
        /// <summary>
        /// Sets up the test fixture.
        /// </summary>
        [FixtureSetUp]
        public void SetUp()
        {
            EstablishContext();
            Act();
        }

        /// <summary>
        /// Carries out the Actions on the System under Test.
        /// </summary>
        protected abstract void Act();

        /// <summary>
        /// Establishes the context for the actions that are to be carried out.
        /// </summary>
        protected abstract void EstablishContext();

        /// <summary>
        /// Tidies up a test fixture.
        /// </summary>
        [FixtureTearDown]
        protected virtual void TidyUp()
        {

        }
    }

It's the TestFixture attribute on this base class that causes the problem. As 
soon as the TestFixture 
attribute is removed here, all the tests start showing up in Resharper as they 
should - no red strike-
throughs.

That allows us to fix the problem at our end, since the TestFixture attribute 
on the base class doesn't seen 
to serve any purpose - except to cause this bug ;-)

Original comment by samuel.j...@gmail.com on 5 May 2009 at 1:35

[GoogleCodeExporter]

Reproduced!  Let's see now...

Original comment by jeff.br...@gmail.com on 14 May 2009 at 8:02

[GoogleCodeExporter]

Found the problem.

This problem occurs because R# first asks us to find the test given an IFile (a 
"Psi"
code model abstraction) and that all works fine.  Later it asks us again to 
confirm
given an IMetadataAssembly (a "Metadata" abstraction) and that fails.

The reason is a bit of a doozy but basically we end up trying to determine 
whether
the [TestFixture] attribute is inheritable.  So we look for the attribute's
[AttributeUsage] attribute.  Then we read the associated AllowMultiple and 
Inherited
properties.

The only problem is that when we ask the IMetadataProperty object corresponding 
to
AllowMultiple for its type, it returns null because we actually we happen to be
looking at an "unresolved" property object which means R# has not resolved the
property metadata from mscorlib (why, I don't know yet).  This code unwinds and
throws a NotSupportedException.

Ultimately we give up trying to do anything with the test so it gets struck out.

Original comment by jeff.br...@gmail.com on 14 May 2009 at 8:36

[GoogleCodeExporter]

It looks like R#'s is returning an IMetadataCustomAttribute for the
AttributeUsageAttribute and it is associated with the wrong assembly.  It 
should be
associated with "mscorlib" but it's actually associated with "MbUnit".

Original comment by jeff.br...@gmail.com on 14 May 2009 at 9:21

[GoogleCodeExporter]

It turns out that the metadata accessor provided by R# is not configured to pull
assemblies from the GAC so assemblies like mscorlib and System cannot be 
inspected. 
I'm surprised I had not noticed this before, but sure enough trying to resolve 
type
System.String produces an UnresolvedTypeInfo object.

What does this all mean for us?  Well, either I will have to find a way to hack 
the
accessor to load more stuff, or I will have to find a way to make due without 
the
ability to load that stuff, or I will have to drop R#'s metadata stuff and use 
Cecil
 instead.

Original comment by jeff.br...@gmail.com on 15 May 2009 at 12:04

[GoogleCodeExporter]

Opened a bug in R# Jira: http://jetbrains.net/jira/browse/RSRP-107904

I have a workaround in place for this case but it is not perfect.

Original comment by jeff.br...@gmail.com on 15 May 2009 at 1:38

[GoogleCodeExporter]

Fixed in v3.0.6 Update 2.

Original comment by jeff.br...@gmail.com on 15 May 2009 at 2:09

• Changed state: Fixed