search

MudassarRasool / mb-unit

Automatically exported from code.google.com/p/mb-unit
0 stars 0 forks source link

NUnit TestCases and Theories display an incorrect hierarchy. #677

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

    [Test]
    public void Test_One()
    {
        Assert.Pass();
    }

    [Test]
    [TestCase(1)]
    [TestCase(2)]
    [TestCase(3)]
    public void Test_Two(int a)
    {
        Assert.Pass();
    }

What is the expected output? What do you see instead?

    Test_Two should exist under the same hierarchy as Test_One, so that the tests can be grouped together when run, etc.  However, Test_Two is incorrectly classified as "Suite", and placed in the hierarchy alongside its own fixture.

What version of the product are you using? On what operating system?

NUnit 2.5.*, Gallio 3.1 build 397

Please provide any additional information below.

Original issue reported on code.google.com by Spoonful...@gmail.com on 1 Jul 2010 at 3:24

GoogleCodeExporter commented 8 years ago 
The output report seems OK to me (see attached picture)
(Gallio 3.2.528 + NUnit 2.5.7.10213)

Did you expect something else?

Original comment by Yann.Tre...@gmail.com on 12 Aug 2010 at 6:18

Attachments:

GoogleCodeExporter commented 8 years ago 
There have been a few changes to the way the tree is generated in 3.2, could 
you try it with the 3.2 RC please?

Original comment by grahamr...@gmail.com on 12 Aug 2010 at 8:18

GoogleCodeExporter commented 8 years ago 
Well, the hierarchy is still weird, but at least it is grouped together under 
the class.

In my install, parameterized tests follow this pattern:

Namespace -> Class -> Namespace (again) -> Test Name -> Test Name Parameters

Which is still incorrect, in my opinion.  The second "Namespace" should be 
removed.

Original comment by Spoonful...@gmail.com on 13 Aug 2010 at 7:12

GoogleCodeExporter commented 8 years ago 
Ah, now I remember! I had a look at this a few weeks ago. Unfortunately the 
tree generation is a bit of a pain, there's so many permutations :( The code 
needs refactoring anyway, I'll put it on the todo list. It's not going to make 
3.2 though, I'm afraid.

Original comment by grahamr...@gmail.com on 13 Aug 2010 at 9:36

GoogleCodeExporter commented 8 years ago 
It looks like the NUnit adapter (latest) doesn't handle parameterized tests 
correctly. I think the attached should help.

Original comment by wayne.br...@gmail.com on 21 Dec 2010 at 6:07

Attachments:

GoogleCodeExporter commented 8 years ago 
Nice. I'm going to apply that patch.

Original comment by Yann.Tre...@gmail.com on 22 Dec 2010 at 7:22

GoogleCodeExporter commented 8 years ago

Original comment by Yann.Tre...@gmail.com on 22 Dec 2010 at 7:27

GoogleCodeExporter commented 8 years ago 
Mmh... ParametrizedTest.cs is missing in the patch.

Original comment by Yann.Tre...@gmail.com on 22 Dec 2010 at 7:32

GoogleCodeExporter commented 8 years ago

Original comment by Yann.Tre...@gmail.com on 22 Dec 2010 at 7:34

GoogleCodeExporter commented 8 years ago 
Yann,

Sorry about that - with SVN I'm constantly forgetting that you need to manually 
add new files. Attached is an updated patch. I would have checked in, but I 
don't have VS2008 on this machine, so I couldn't easily test the sync of the 
two projects.

I did notice that two of the three NUnit adapter projects (including Latest) 
are missing from the All.vs2010 solution - I guess that's because they're 
missing from the 2008 solution also. Should we add them?

Original comment by wayne.br...@gmail.com on 26 Dec 2010 at 1:14

Attachments:

GoogleCodeExporter commented 8 years ago 
Applied. Thanks a lot, Wayne.

All.*.sln are not used by the build process. And I actually do not recommend to 
use it (it's terribly long to open and build a solution with 100+ projects!) I 
prefer using Gallio.*.sln once for the core binaries, then the specific 
projects for each extension/adapter/runner/etc.

Original comment by Yann.Tre...@gmail.com on 26 Dec 2010 at 12:18

GoogleCodeExporter commented 8 years ago 
Ah, OK. But if we're not going to maintain those solutions we should probably 
remove them. They're the natural starting point for a new contributor, and it's 
confusing when you project load errors right out of the gate.

Original comment by wayne.br...@gmail.com on 26 Dec 2010 at 4:44