Backwards compatibility with C# Reflection and NUnit Versions

Question

I am using C# on the .NET 4.5 framework with Visual Studio 2015. I am attempting to plug NUnit support into an automated test system that was built around MSUnit tests. As part of the system, I need to find methods marked with TestAttribute and TestCaseAttribute in provided .dll files using Reflection. Currently this system has NuGet packages installed for NUnit version 3.2.1.

Question: is there a way to detect these attributes on tests that were created using older versions of NUnit? For example, I have some tests that were created using NUnit version 2.6.4, but their corresponding attributes are not found because the system is looking for attributes from NUnit 3.2.1.

Here is a snippet of code used to detect the test classes marked with TestFixtureAttribute in the provided .dll:

var testClasses = testAssembly
            .SelectMany(a => a.GetTypes())
            .Where(a => a.IsDefined(typeof(TestFixtureAttribute), false));

Again, this snippet doesn't find any test classes on the provided .dll because the older TestFixtureAttribute is not the same as the one in NUnit 3.2.1

I have successfully run older NUnit tests on the nunit3-console.exe, so discovering the tests is the big roadblock for now.

Thanks in advance for any help!

why don't you just upgrade the references on the "old" unit tests. I don't think a lot changed between them versions. I'd be surprised if upgrading broke your unit tests. It's better to just pick a version and then use it everywhere — Liam
I'm but a lowly intern, so I can definitely discuss this with my mentor and manager. I'm sure it would be easy enough to make sure people using the system know which version of NUnit they must use. — Charles.Goepfert
This question is probably better suited to the NUnit Discuss mailing list. I can help you find the attributes, but I would like to know more about what you do with the tests once you find them. That will require back and forth which isn't well suited to SO. Your first post will be moderated, but we will approve it quickly. groups.google.com/forum/#!forum/nunit-discuss — Rob Prouse
If you just want to solve your problem though, the solution is to look at the string name of the attributes, rather than the types. — Rob Prouse

Charlie Charlie · Accepted Answer · 2016-06-23T16:35:09

This may not get a lot of votes, but my answer would be "Don't do that!" And this won't fit in a comment anyway. :-)

NUnit 3.x has an API for running tests. Discovering them yourself by looking for attributes means that you have to update your application every time somebody (including your own users) adds a new attribute that identifies tests. It also means you have to figure out the semantics of running an NUnit test and duplicate every twist and turn of how NUnit does it.

That's how it was done in the "old days" - by which I mean in NUnit V2 and also in MsTest. One of the main goals in creating NUnit 3 was to provide an API that would get rid of the need for third-party runners to duplicate the logic that's already inside NUnit.

Even without waiting for the future to break your implementation, you can see the impact of change on it right now. If you handle Test and TestCase attributes, what about... * TestCaseSource * TestFixture * TestFixtureSource * Values * Random * Range * Combinatorial * Sequential * Pairwise (That's out of my head... I probably missed something)

OTOH, you can limit your exposure to a couple of interfaces you call to run tests. If you are writing something that needs to integrate in an IDE, it gets a bit more complex but that will be the case no matter how you do it.

If you decide to use the API, follow Rob's advice and come to our forum to discuss details as they arise.

Backwards compatibility with C# Reflection and NUnit Versions

1 Answers