zastrowm / nunit.applicationdomain Goto Github PK

^{Issue created by Izzy Coding as Bitbucket Issue #​25 on 2018.08.06 10:59.}
I have a base unit-testing support library which uses NUnit 3.9.0
I am using VS2017 with ReSharper & NUnit3TestAdapter installed
When I add a test as described in the documentation, nothing seems to appear in the test runner.
Also if I run the tests on my CI environment (which uses NUnit command-line calls), it doesn't run the tests.

^{Issue created by qmfrederik as Bitbucket Issue #​13 on 2016.03.23 17:51.}
Hi!

I've tried to run NUnit.ApplicationDomain on Linux/Mono and hit an issue where ParentAppDomainRunner.GetPermissionSet would throw an exception because CAS in general and Evidence.AddHostEvidence in particular are not implemented on Mono.

The solution is easy - just return new PermissionSet(PermissionState.Unrestricted); if running on Mono.

I've implemented a POC fix @ https://github.com/quamotion/nunit.applicationdomain/commit/16fb4a66a3c90e6582e16db7b9127305c1dbb98c although you may want to dynamically detect whether Mono is running instead of doing it dynamically.

Hope it helps

^{Issue created by @tpluscode as Bitbucket Issue #​3 on 2014.08.19 08:29.}
Hi

I have test setup like this

public abstract class TestsBase 
{
   [Test]
   public void SomeTest()
   {
   }

   protected abstract void SomeChildSetup();
}

[TestFixture]
public abstract ActualTestClass : TestsBase
{
   [Test]
   public void AdditionalTest()
   {
   }

   protected override void SomeChildSetup()
   {
   }
}

This works fine with NUnit. I can have multiple test fixtures with shared tests and customized setup.

I would like to annotate ActualTestClass with [RunInApplicationDomain], but currently it throws an exception for each inherited test method, because TestsBase is abstract.

I guess it's because you are looking at methods' declaring type and not actual type? Would it be hard to make such setup work?

^{Issue created by <unknown> as Bitbucket Issue #​4 on 2014.10.07 14:43.}
The testrunner fails because it cannot load dependent dll's (namely NUnit itself) into the new AppDomain.

The reason is, that
info.ApplicationBase = Path.GetDirectoryName(new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath);
in AppDomainRunner will only take the part of the path up to the first URI unfriendly part.

C:\Projects\C#\Company\src will thus become C:\Projects\C

suggested solution is to use:

info.ApplicationBase = Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase.Replace("file:///", "").Replace("/", "\"));

^{Issue created by @zastrowm as Bitbucket Issue #​8 on 2015.04.10 18:47.}
5.X will break existing users as the api is changed. This should be documented along with the "new way" of doing things.

We should also add a contributors.txt

^{Issue created by @jlewin as Bitbucket Issue #​16 on 2016.09.21 13:25.}
Repro

1. Create a Test marked with the RunInApplicationDomain
2. Add the following line of code
   string testDirectory = TestContext.CurrentContext.TestDirectory;
3. Run the test

Expected

String value with the directory containing the current test assembly

Actual

Exception thrown: 'System.Runtime.Serialization.SerializationException' in nunit.framework.dll

Example from Each_test_is_in_different_appdomain test

Instance Properties

^{Issue created by @zastrowm as Bitbucket Issue #​7 on 2015.04.09 22:19.}
We have multiple contributors now; their contributions should be noticed (if they wish)

^{Issue created by @zastrowm as Bitbucket Issue #​22 on 2016.11.14 22:17.}

ExceptionDispatchInfo.Capture(ex.InnerException).Throw();

Not sure why this isn't already in for the stack traces.

^{Issue created by @zastrowm as Bitbucket Issue #​6 on 2015.04.09 22:19.}
5.X will break existing users as the api is changed. This should be documented along with the "new way" of doing things.

We should also add the new features that have been added since 3.0+ such as multiple teardown/setup, fixture teardown/setup, data-driven tests, app.config support etc.

^{Issue created by <unknown> as Bitbucket Issue #​24 on 2018.07.16 16:28.}
It looks like the latest version of NUnit has made some changes that breaks this package, once again.

After updating my test project to NUnit 3.1.0.1, the tests I have that use NUnit.ApplicationDomain are failing:

System.MissingMethodException : Method not found: 'NUnit.Framework.Interfaces.IPropertyBag TestAdapter.get_Properties()'.
TearDown : System.TypeInitializationException : The type initializer for 'DynamicAssembly' threw an exception.
  ----> System.MissingMethodException : Method not found: 'NUnit.Framework.Interfaces.IPropertyBag TestAdapter.get_Properties()'.
   at NUnit.Framework.AppDomainRunner.get_DataStore()
   at NServiceBus.Core.Tests.AssemblyScanner.AssemblyScannerTests.SetUp()
--TearDown
   at NServiceBus.Core.Tests.AssemblyScanner.AssemblyScannerTests.TearDown()
--MissingMethodException
   at NUnit.Framework.AppDomainRunner.get_DataStore()
   at NServiceBus.Core.Tests.AssemblyScanner.AssemblyScannerTests.DynamicAssembly..cctor()

^{Issue created by <unknown> as Bitbucket Issue #​10 on 2015.10.21 09:26.}
Could you release this addon for nunit3?
I've tried to do this for myself and it looks like it could be done easily:

1. In CurrentArgumentsRetriever.cs
   -load arguments from property "Arguments" instead of field "arguments"
   -load context property from assembly "nunit.framework" using type "NUnit.Framework.Internal.TestExecutionContext"
2. Replace obsolete TestFixtureSetup/TestFixtureTearDown attributes with -OneTimeSetup/OneTimeTeardown
3. For RunInApplicationDomainAttribute
   -replace TestDetails with ITest in BeforeTest/RunInApplicationDomain methods signature
   -load types from testDetails.TypeInfo, testDetails.Method.TypeInfo, typeUnderTest.Type

With those small changes I've made all your tests green

^{Issue created by jeromerg as Bitbucket Issue #​2 on 2013.12.13 04:57.}
Hi,

I just wanted to report a problem I had by using this framework, to help other developer to find quicklier a solution:
My unit test automate WPF controls. With Resharper in visual studio, the unit tests run well. But with the NUnit GUI or console, the UNit tests throw the exception:

System.InvalidOperationException : The calling thread must be STA, because many UI components require this.

Fortunately, I could fix the problem by adding the NUnit annotation [RequiresSTA] on the tests!

I say fortunately because the thread running the test in the sub-AppDomain inherits the property of the calling thread, which is configured by the Annotation [RequiresSTA]...

^{Issue created by @rubenhak as Bitbucket Issue #​19 on 2016.10.15 13:59.}
The NUnit.ApplicationDomain requires test arguments to be Serializable. It indeed might be a valid requirement, but when an argument is not serializable the test infra hangs in "Cancelling" state waiting for the text execution to be terminated.

The test returned following error:
System.Runtime.Serialization.SerializationException : Type 'MyType' in assembly 'MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable.

private static MyType[] MyTestData = new[]{
            new MyTestData(1),
            new MyTestData(2),
            new MyTestData(3),
            new MyTestData(4)
            };


[Test]
[RunInApplicationDomain]
public void MyTest([ValueSource("MyTestData")]MyType testData)
{

}

^{Issue created by <unknown> as Bitbucket Issue #​11 on 2015.11.19 03:29.}
Please add RequiresSTA support.

^{Issue created by @rubenhak as Bitbucket Issue #​20 on 2016.10.15 17:46.}
Hi,

I just started using "NUnit.ApplicationDomain" and am very close to resolve a major nightmare with common app domain, but I'm hitting an issue. In my tests I heavily use TestFixtures and test class constructors with parameters. Something like this:

    [TestFixture((uint)1, (uint)0, (uint)1, (uint)0, (uint)0)]
    [TestFixture((uint)1, (uint)0, (uint)0, (uint)1, (uint)0)]
    [TestFixture((uint)1, (uint)0, (uint)0, (uint)0, (uint)1)]
    [TestFixture((uint)1, (uint)100, (uint)1, (uint)0, (uint)2)]

class MyTest
{
        public MyTest(uint a, uint b, uint c, uint d, uint e)
        {

        }
}

This configuration does not seem to be supported. Is there any workaround? Looked through the code and found that the actual failure happens in InDomainTestMethodRunner, line "Activator.CreateInstance(typeUnderTest);". First thing that comes to my mind is to provide an ability for the test class to copy certain values from original test. Another way would be to extract the parameters array from the TestFixture and pass those as parameters to CreateInstance.

I'd appreciate your help here.

Thanks,
Ruben

^{Issue created by @zastrowm as Bitbucket Issue #​9 on 2015.04.28 19:10.}
The runner requires the class under test to be public. We should investigate if this is really needed or was an artifact of initial development

^{Issue created by jeromerg as Bitbucket Issue #​1 on 2013.11.29 03:51.}
Hi,
very nice plugin.
NUnit config the test-appdomain with the assembly.config file, if it exists. This feature is missing in the separate appdomain.
I added the feature locally on my machine. As attachment, I add the two files I modified for this purpose. If you give me the right to make a pull-request I can propose a patch.

^{Issue created by hubert abendroth as Bitbucket Issue #​5 on 2014.11.12 02:19.}
I found out, that the execution of a test method marked with RunInApplicationDomain is preceded by TWO calls to the method decorated with [Setup].

The first call takes place within the regular testing domain, the second within the isolation domain created by AppDomainRunner.

Likewise [TearDown] is called twice as well after running the test.

^{Issue created by @rubenhak as Bitbucket Issue #​21 on 2016.10.25 01:37.}
Hi,

First of all want to tell you that NUnit.ApplicationDomain solves a big problem with isolating testing environment. I've been using it for couple of weeks now and it was very helpful. Now I'm hitting a different kind of issue - performance. I heavily rely on TestFixtures and TestCasses that already produced 4K test cases. I've noticed that creation and unload of 4K AppDomains increases the test run time from 2 minutes to 20 minutes. Here is my proposal:

In some cases full app domain isolation is not needed. I designed my software so that there is almost no global state, and the global state I can isolate internally using "some magic namespaces". But when test case instances are holding lots of state that is specific to individual test run. So for every test run within the test fixture I needed a separate instance, just like that way it is done in NUnit.ApplicationDomain. So, I'm thinking about a way to reuse the work done and for certain tests still create new instance of test object, but execute it in the default app domain.

I put together a prototype by just commenting out AppDomain creation, instanciated InDomainTestMethodRunner and just executing the methodData. One extra trick was needed. The test instance should have information whether it is a original instance, or the cloned one. One way is to implement the interface:

    public interface IReusableTestFixture
    {
        void MarkAsExecutableTest(bool isExecutable);
    }

And after creating the copy:

      object instance;
      if (testMethodInfo.FixtureArguments == null)
      {
        instance = Activator.CreateInstance(typeUnderTest);
      }
      else
      {
        instance = Activator.CreateInstance(typeUnderTest, testMethodInfo.FixtureArguments);
      }

      if (instance is NUnit.Framework.IReusableTestFixture)
      {
         ((NUnit.Framework.IReusableTestFixture)instance).MarkAsExecutableTest(true);
      }

The text would return from [Init] and [CleanUp] if the call was make for the instance which was not set to be Executable.

Basically this is the rough idea. It would be very nice to have this functionality. Let me know if you see value in this and we can collaborate.

Cheers,
Ruben

^{Issue created by <unknown> as Bitbucket Issue #​15 on 2016.08.26 02:44.}

[TestFixture, RunInApplicationDomain]
public class TestTemp
{
    [SetUp]
    public void Prepare()
    {
        Console.WriteLine("setup: " + AppDomainRunner.IsInTestAppDomain);
    }
    [Test]
    public void TestFail()
    {
        Console.WriteLine("Test: " + AppDomainRunner.IsInTestAppDomain);
        Assert.Fail("fail; TearDown will not run in TestAppDomain");
    }
    [Test]
    public void TestSuccess()
    {
        Console.WriteLine("Test: " + AppDomainRunner.IsInTestAppDomain);

// Assert.Fail("fail; TearDown will not run in TestAppDomain");
}

    [TearDown]
    public void Down()
    {
        Console.WriteLine("TearDown: " + AppDomainRunner.IsInTestAppDomain);
    }
}

^{Issue created by @zastrowm as Bitbucket Issue #​17 on 2016.09.21 13:34.}
Currently it exists to share data, but it's not currently exposed.

Hi,

Thanks for creating this library! We have been using to isolate some complex assembly scanning tests and it worked great.

Have you considered providing .NET support too?
Currently, we are only executing the tests on .NET Framework but we are moving away from it. Ideally, we would love to keep the assembly scanner tests.

Daniel

Hello,

IMHO it is a bad idea to use application bindings, we only use them if nothing else is feasable.

This package hasn't been updated in a while.
Could it be updated to be compatible with a newer version of NUnit.Framework ?

Thank you

^{Issue created by angularsen as Bitbucket Issue #​18 on 2016.10.14 15:02.}
It seems the [OneTimeTearDown] annotated method runs as soon as I await anything in the test method, instead of after completing the test method asynchronously. The test method returns a Task so it works as expected when not annotating the test method with [RunInApplicationDomain].

Is this a known issue or am I possibly mistaken?

^{Issue created by @zastrowm as Bitbucket Issue #​14 on 2016.04.12 00:34.}
LarsSkovslund/NuGet.Package.Builder#10 (comment)

^{Issue created by jamesjohnmcguire as Bitbucket Issue #​12 on 2015.12.28 06:40.}
When attempting to use this from a signed assembly (thus, with a strong name), I get the following compile error:
Error 1 Assembly generation failed -- Referenced assembly 'NUnit.ApplicationDomain' does not have a strong name

There are workarounds for this using ildasm, ilasm and sn tools, so this isn't urgent. But having the assembly signed couldn't hurt, in any case.

^{Issue created by @bording as Bitbucket Issue #​23 on 2017.07.24 23:33.}
I was recently trying to update some projects that use NUnit.ApplicationDomain to NUnit 3.7.1 from 3.6.1, but I was unable to because it appears this this package is not compatible with the latest version of NUnit.

Do you have any plans to support newer versions of NUnit?