Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NUnit3TestAdapter 3.15 OneTimeSetUp not working anymore #649

Closed
f-bourqui opened this issue Aug 27, 2019 · 12 comments
Closed

NUnit3TestAdapter 3.15 OneTimeSetUp not working anymore #649

f-bourqui opened this issue Aug 27, 2019 · 12 comments
Labels
closed:done is:bug resolution:known We have a resolution for this, which is described in the issue, under heading Resolution
Milestone

Comments

@f-bourqui
Copy link

Visual Studio 2017 v15.9.14

The first time I run a test, OneTimeSetUp is called, then every other runs fails. I had no problems with 3.14. I made a new project to reproduced it with minimal code and I can run multiple time my test and it always succeed with 3.14, but as soon as I upgrade to 3.15, it is never called anymore.. If I restart VS, it work only once and all following try fails. Can be reproduced with nuget package or VS extension.

using NUnit.Framework;

namespace NunitAdapter315Bug
{
    [SetUpFixture]
    public class ProjectSetup
    {
        public static bool oneTimePassed = false;

        [OneTimeSetUp]
        public void OneSetup()
        {
            oneTimePassed = true;
        }
    }
}
using NUnit.Framework;

namespace NunitAdapter315Bug
{
    [TestFixture]
    public class TestNunitAdpaterTest
    {
        bool setupPassed = false;
       
        [SetUp]
        public void Setup()
        {
            setupPassed = true;
        }

        [Test]
        public void TestIt()
        {
            Assert.IsTrue(ProjectSetup.oneTimePassed);
            Assert.IsTrue(setupPassed);
        }
    }
}

@MattKeenum
Copy link

I am able to reproduce this issue with the above code. However, if I have the TestNunitAdapterTest class inherit from ProjectSetup, everything works as expected. Not sure if this is intended behavior or not.

namespace NUnitTest
{
    [SetUpFixture]
    public class ProjectSetup
    {
        public static bool oneTimePassed = false;

        [OneTimeSetUp]
        public void OneSetup()
        {
            oneTimePassed = true;
        }
    }

    [TestFixture]
    public class TestNunitAdpaterTest : ProjectSetup
    {
        bool setupPassed = false;

        [SetUp]
        public void Setup()
        {
            setupPassed = true;
        }

        [Test]
        public void TestIt()
        {
            Assert.IsTrue(oneTimePassed);
            Assert.IsTrue(setupPassed);
        }
    }
}

@mikkelbu
Copy link
Member

I'm quite sure that this is the same problem as in nunit/nunit#3356 (see the comments for more info), but I've not had time to look into how to fix it.

@ggeurts
Copy link

ggeurts commented Aug 28, 2019

I have also had to revert to version 3.14 because tests in .NET Core started failing due to not running of SetUpFixture with OneTimeSetup method.

@jhbell
Copy link

jhbell commented Aug 28, 2019

If anyone else is having trouble downgrading to version 3.14 to avoid this bug, here are the steps I took:

  1. Uninstall NUnit3TestAdapter from Visual Studio and make sure auto-update for your extensions are turned off.
  2. Download the NUnit3TestAdapter-3.14.0.vsix file from the releases page here. (Under Assets)
  3. Double click the .vsix file which will launch the VSIX Installer and install 3.14 on your desired version of visual studio.

@OsirisTerje
Copy link
Member

Thanks @jhbell !

Will try to get out a fix within this week, probably using a feature flag to enable/disable the pre-filtering.

@OsirisTerje OsirisTerje added this to the 3.15.1 milestone Aug 28, 2019
@OsirisTerje OsirisTerje added resolution:unknown We don't know yet how to resolve this issue resolution:known We have a resolution for this, which is described in the issue, under heading Resolution and removed resolution:unknown We don't know yet how to resolve this issue labels Aug 28, 2019
@viceice
Copy link

viceice commented Aug 29, 2019

@jhbell Your solution only works for the vsix, we don't use that. We have to downgrade the NUnit3TestAdapter package reference to 3.14.0

@OsirisTerje
Copy link
Member

@viceice Downgrading a nuget package is much more simple than the vsix, since all you have to do is either : 1) Use the Tools/Manage nugetpackages in Visual Studio and select the 3.14 version 2) If you have a SDK based project, just edit the csproj file directly. :-)

However, the fix is on its way now, a PR is up, waiting for a quick review. Hopefully we can get it out tomorrow, Aug 30.

@OsirisTerje
Copy link
Member

@SmartLibertyFBO @ggeurts @viceice There is now a beta version of the fix in https://www.myget.org/feed/nunit/package/nuget/NUnit3TestAdapter/3.15.1-dev-01134 . Would appreciate if you checked it.

@viceice
Copy link

viceice commented Aug 29, 2019

I can test it earliest on monday

@OsirisTerje
Copy link
Member

@SmartLibertyFBO 3.15.1 hotfix released now.

@f-bourqui
Copy link
Author

It seems to work with my test solution, thanks

@viceice
Copy link

viceice commented Sep 3, 2019

Works here

jonpryor pushed a commit to dotnet/android that referenced this issue May 9, 2023
With the new auto-retry for failed emulator tests (bff7242) we are
seeing some weird results.  For example:

The first run failed with:

	Failed DotNetInstallAndRun(True,True,"net8.0-android") [12 m 11 s]
	  Error Message:
	     `dotnet run` should succeed
	  Expected: True
	  But was:  False

	  Stack Trace:
	     at Xamarin.Android.Build.Tests.XASdkDeployTests.DotNetInstallAndRun(Boolean isRelease, Boolean xamarinForms, String targetFramework) in /Users/builder/azdo/_work/1/s/xamarin-android/tests/MSBuildDeviceIntegration/Tests/XASdkDeployTests.cs:line 87
	     at Xamarin.Android.Build.Tests.XASdkDeployTests.DotNetInstallAndRun(Boolean isRelease, Boolean xamarinForms, String targetFramework) in /Users/builder/azdo/_work/1/s/xamarin-android/tests/MSBuildDeviceIntegration/Tests/XASdkDeployTests.cs:line 87

The retry failed with:

	Failed DotNetInstallAndRun(True,True,"net8.0-android") [1 s]
	Error Message:
	 System.InvalidOperationException : Unknown abi: 
	Stack Trace:
	   at Xamarin.ProjectTools.AbiUtils.AbiToRuntimeIdentifier(String androidAbi) in /Users/builder/azdo/_work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Utilities/AbiUtils.cs:line 18
	 at Xamarin.ProjectTools.ProjectExtensions.SetRuntimeIdentifier(IShortFormProject project, String androidAbi) in /Users/builder/azdo/_work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tests/Xamarin.ProjectTools/Utilities/ProjectExtensions.cs:line 34
	 at Xamarin.Android.Build.Tests.XASdkDeployTests.DotNetInstallAndRun(Boolean isRelease, Boolean xamarinForms, String targetFramework) in /Users/builder/azdo/_work/1/s/xamarin-android/tests/MSBuildDeviceIntegration/Tests/XASdkDeployTests.cs:line 76
	 at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
	 at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

There are other instances of tests failing with this message,
including timing tests that initially failed simply because the
process took too long to finish.

It seems like the valid ABIs aren't getting set on the second run,
which is done via `[OneTimeSetUp]`.  As crazy as this seems, since
the second run is a completely new process, this does appear to have
been [a bug in NUnit at some point][0].

I am not sure if all of our NUnit assemblies have been updated enough
to contain the fix for this.  Since it's a good idea to update to the
latest anyways, this PR updates us to the latest version of NUnit and
hopes it fixes the issue.  🤷‍♂️

[0]: nunit/nunit3-vs-adapter#649
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed:done is:bug resolution:known We have a resolution for this, which is described in the issue, under heading Resolution
Projects
None yet
Development

No branches or pull requests

7 participants