Why is the Visual Studio 2015/2017/2019 Test Runner not discovering my xUnit v2 tests

Question

UPDATE: Adding a 2019; the discovery/runner integration mechanism is same as per 2017 & 2015, so the key things that can go wrong are the same.

---

I've read Why is the xUnit runner not finding my tests, which covers reasons xUnit would never be able to find your tests but my problem is different - I'm confident there's nothing subtle going on with my tests; (they have worked in other environments, this seems to be just my machine) - the Visual Studio Test Runner in Visual Studio 2015 [Community Edition] is simply not showing any of my tests. I'm not doing anything remotely exciting; the tests target xUnit.net v2 on the Desktop.

I've looked in the Output window and am not seeing anything in at all under Test in the Show output from tabs.

Audwen

related: #16215184 – Audwen

It is just one possible problem, but obviously you have to compile the test project before it will be shown in the test explorer. – Owings

related: https://mcmap.net/q/119921/-visual-studio-2015-or-2017-does-not-discover-unit-tests – Audwen

This worked for me - #42862430 – Evanston

Installing Xunit.Runner.VisualStudio has resolved my problem – Homogamy

Installing Xunit.execution.desktop solved the issue for me – Dalessandro

I had this problem, by forgetting to make my new test class public. – Rum

Answer 1

1. Eliminate discovery exceptions from your inquiries; go to the output Window (Ctrl-Alt-O), then switch the show output from dropdown (Shift-Alt-S) to Tests and make sure there are no discovery exceptions

2. Test|Test settings|Default processor architecture can help if your tests are x86/x64 specific and discovery is triggering bittedness-related exceptions, i.e. not AnyCpu

3. As suggested in this answer(upvote it if the technique helps) running the desktop console runner (instructions) can be a good cross check to eliminate other possibilities, e.g. mangled config files:-

> packages\xunit.runner.console.2.2.0\tools\xunit.console <tests.dll>

NOTE The xunit.runner.console package is deprecated - when you get stuff working in VS, you'll be able to have dotnet test run them in CI contexts too

---

Go read the documentation - it's comprehensive, up to date, includes troubleshooting info and takes PRs:-

Important note: If you've previously installed the xUnit.net Visual Studio Runner VSIX (Extension), you must uninstall it first. The Visual Studio runner is only distributed via NuGet now. To remove it, to go Tools > Extensions and Updates. Scroll to the bottom of the list, and if xUnit.net is installed, uninstall it. This will force you to restart Visual Studio.

If you're having problems discovering or running tests, you may be a victim of a corrupted runner cache inside Visual Studio. To clear this cache, shut down all instances of Visual Studio, then delete the folder %TEMP%\VisualStudioTestExplorerExtensions. Also make sure your project is only linked against a single version of the Visual Studio runner NuGet package (xunit.runner.visualstudio).

The following steps worked for me:

0. (Only if you suspect there is a serious mess on your machine - in general the more common case is that the visual studio integration is simply not installed yet)

Do the DEL %TEMP%\VisualStudioTestExplorerExtensions as advised :-

PS> del $env:TEMP\VisualStudioTestExplorerExtensions

1. Install the NuGet Package xunit.runner.visualstudio in all test projects

   • Paket:

       .paket\paket add nuget xunit.runner.visualstudio -i
     

     You need to end up with the following in your paket.dependencies:

     nuget xunit.runner.visualstudio version_in_path: true
     

     Note the version_in_path: true bit is important

   • Nuget: Go to Package Manager Console (Alt-T,N,O) and

     Install-Package xunit.runner.visualstudio
     

   Rebuild to make sure xunit.runner ends up in the output dir

2. Close Test Explorer <- this was the missing bit for me

3. Re-open Test Explorer (Alt-S,W,T)

4. Run All tests (Ctrl R, A)

Audwen

"Close Test Explorer <- this was the missing bit for me" This is the most important step that I missed as well and spent 5 hours to figure out. Thank you, I should have paid attention to the steps :) – Valli

the xunit VS runner was working for my sln. However, it had stopped showing up one day. Found out that I did not installed the VS running, and it was working probably because of the cache, left by the other sln which has the runner installed. After installing the runner, things work fine again. So don't forget to install the runner for every sln. – Brezin

This is unbelievable. Deleting the folder that had three other empty folders in it fixed the issue. – Neidaneidhardt

@Neidaneidhardt It probably had 50 hidden files and a wierd permission ;) (maybe it was created by a different user identity?) – Audwen

Your first sentence was the key for me. The Test window showed I had the wrong version of NUnit. – Pfeffer

I missed the public keyword on my test class -_- – Sheena

@martinJH I have a self answered one for that (Linked in OP) :- #16215184 ;) Not revealing how I discovered that though – Audwen

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv /resetuserdata could also fix your problem in my experience – Enrika

@seb2day not seeing any info re that suggesting a direct connection so will not edit in for now (it seems TFS Cache related blogs.msdn.microsoft.com/ejarvi/2005/07/14/… and is not documented in 2015 or 2017 anymore, although there is a resetsettings learn.microsoft.com/en-gb/visualstudio/ide/reference/… ) – Audwen

Closing and reopening Test Explorer helped me, but it didn't work the first time. I can usually get test explorer to discover tests but I haven't figured out what consistently works. – Deason

Removing %TEMP%\VisualStudioTestExplorerExtensions did it for me – Banting

Really weird stuff, but deleting %TEMP%\VisualStudioTestExplorerExtensions and restarting VS finally worked! – Uracil

Thanks mate! My issues solved by Point 3. I can't believe that the testing framework won't change accordingly. – Spheroidal

For some reason I had to use the keyboard shortcut to run all tests (Ctrl+R,A) before the Test Explorer would recognize my tests. For some reason clicking the Run All button with the mouse wouldn't find any tests. – Claude

Note that on my machine with VS 2019 pro there was no %TEMP%\VisualStudioTestExplorerExtensions folder. Instead I had to delete `.vs` in the solution root – Household

Unfortunately I don't have the rep to post an answer. However, I just want to say that I encounter this issue intermittently. I did a Close Solution, then I reopened the solution, and my tests were discovered. So that's one more thing for people to try if this is just happening intermittently. – Detrain

Answer 2

None of the above solutions worked for me (dotnetcore 1.1, VS2017). Here's what fixed it:

1. Add NuGet Package Microsoft.TestPlatform.TestHost
2. Add NuGet Package Microsoft.NET.Test.Sdk

Those are in addition to these packages I installed prior:

• xunit (2.3.0-beta1-build3642)
• xunit.runner.visualstudio (2.3.0-beta1-build1309)

Tressatressia

This helped me, i was missing xunit.runner.visualstudio package. – Whang

My .NET 4.72 MS Test project needed TestPlatform.TestHost only when migrating from VS 2017 to VS 2019. – Cupcake

This solved it for me. In the Output window, select Tests from the drop down => see message "missing TestHost" message. – Dapplegray

Microsoft.NET.Test.Sdk worked for me. I didn't need to add Microsoft.TestPlatform.TestHost – Mussman

Answer 3

I had to change the Test Settings after changing the test projects CPU to x64. Then the tests where detected again.

Coagulate

Did you see a message before that in the test discovery output? – Audwen

No I didn't see any errors, it took a while to figure out. – Coagulate

hmm; strange (see top of my answer - it explains where to look; normally this is flagged (though there are def cases where there simply are no messages anywhere)) – Audwen

This fixed it for me. I don't know why this helps, but it does. – Antiseptic

I had to clean --> rebuild after changing. – Allelomorph

Answer 4

Install xunit.runner.visualstudio package for the test project

Libertinism

Already installed, but upgrading the version through nuget got it working again. – Headlong

Precise solution, works for VS 2019 – Estop

Also works on VS 2022 – Gag

Answer 5

Make sure that your test class is public.

Undo

thats explicitly addressed in the first proviso (I link t another question that covers that case); this Q+A is only about troubleshooting how how normally OK tests that work in other places dont work for someone righjt now in a given environment. For me this answer just confuses matters as it dilutes that distinctino. – Audwen

Answer 6

Follow this steps :

1. Update your MsTest.TestAdapter and MsTest.TestFramework dll's from nugget package manager.
2. Clean your solution
3. Build your solution.

Riha

Can you open a clone of this question and self answer please as I have done? This one is about xUnit v2 and later. Even xUnit v1 answers have no place here. You can link to it with a see also at the top of the question, or I can link to it in the question – Audwen

This solution works.. Otherwise everytime i had to remove %TEMP%\VisualStudioTestExplorerExtensions and still sometimes i had to run the tests from console. – Vadose

I am using NUnit and I solved this issue by updating NUnit3TestAdapter to the latest version via NuGet. – Clarissa

Thanks for this - in my instance just had to Update-Package -reinstall MSTest.TestAdapter and the tests got picked up. – Felizio

Answer 7

I've been struggling with this all afternoon whilst working with an ASP Core project and xUnit 2.2.0. The solution for me was adding a reference to Microsoft.DotNet.InternalAbstractions

I found this out when trying to run the test project manually with dotnet test which failed but reported that InternalAbstractions was missing. I did not see this error in the test output window when the auto discovery failed. The only info I saw in the discovery window was a return code, which didn't mean anything to me at the time, but in hindsight was probably indicating an error.

Grimbal

"but reported a useful error" ... which was ? Also can you verify it was definitely not listed in the discovery errors window as stated in the OP - i.e. can you confidently state "I've looked in the Output window and am not seeing anything in at all under Test in the Show output from tabs." ? – Audwen

See updated answer, I will post the return code info later on in case it is relevant. – Grimbal

Answer 8

It's happened to me a couple of times - when I Clean the project and Build it again it tends to be fine.

Amphibious

any telltale messages when you look in the output window with Tests selected in the dropdown? – Audwen

None at all, it just says No tests found – Amphibious

In my case, Test Explorer was hanging on a previously failed test. If I browsed to it and tried to right click -> Run or anything then the whole VS would hang. Just doing a Clean and Rebuild cleared the test status and fixed the issue for me. – Washerman

May I add that simply building (i.e. F6) won't help, you need to right-click on the solution in VS Solution Explorer and click Rebuild Solution. – Washerman

Answer 9

I had the same issue with Visual Studio 2019. Just Installed the following NuGet packages and the issue was solved.

1). xUnit

2). xunit.runner.visualstudio

3). Microsoft.TestPlatform.TestHost

4). Microsoft.NET.Test.Sdk

Villanovan

Answer 10

After spending 2 days... none of the above worked for me. The only "solution" was: Go to project properties -> Build Tab. Then click Advanced button on the right bottom corner of the pane. Change "Debug Info:" to "full" and click OK.

Here are the screen shots:

Breakneck

sounds painful. Thanks for sharing and hope it helps someone some day. However I have to say: I can't think of any reason for the debug info level to affect the discovery process so I can only say "I don't think that was what actually shot the bear" - let's hope I'm wrong though ;) – Audwen

@RubenBartelink completely agree with you, that is why I mentioned "solution" in a quote :) but weird enough, it worked right away once I did this. – Breakneck

Thank you very much. This was also the fix for me :) – Lionellionello

Answer 11

The reason in my case was the target build was not the same between project debugger and test runner. To unify those elements:

1. Test>Test Settings>Default Processor Architecture. then select either X64 or X86.
2. Project>(your project)Properties>Build(tab)>platform target.

After they are identical, rebuild your solution then test methods will appear for you.

Sian

Answer 12

I am using xUnit 2.2.0.

My issue was my solution was not able to find certain dlls and app.config was trying to resolve them. The error was not showing up in the test output window in Visual Studio.

I was able to identify the error when I installed xunit.runner.console and tried to run the tests through command line.

How to run xunit tests in CLI.

Impanation

Answer 13

I can provide a solution for an edge case I ran into a few days ago. It's not gonna be the solution that fits all of the scenarios described above, however, for the edge case I had it fixed it.

I had the same issue with most recent VS 2017 (version 15.5.7) and XUnit 2.3.1. The xunit.runner.visualstudio package was installed, however, the tests didn't show up in VisualStudio's built-in test explorer.

I was working on a legacy project that was targeting .NET framework 4.5. However, beginning with version 2.2. XUnit does not support .NET frameworks lower thant 4.5.2 (see Release Notes - XUnit 2.2: February 19, 2017

Changing the test project's target framework to a version >= 4.5.2 worked for me. You don't have to change the project's version that you're testing, it's just about the test project itself.

Brandish

Answer 14

This can also be due to the build check box not being ticked for the current platform project in the build configuration. Click Build | Configuration manager, then make sure the test projects have a tick in the build column for the platform that you're using (for example 'x86').

This was definitely the solution that worked for me.

Twentyfourmo

I would upvote this if it was on #16215184 as this is not xunit2 specific and a good checklist element – Audwen

Answer 15

Do make sure that you haven't written your unit tests in a .NET Standard 2.0 Class Library. The visualstudio runner does not support running tests in netstandard2.0 class libraries at the time of this writing.

Check here for the Test Runner Compatibility matrix:

https://xunit.net

Combination

Both links are dead. – Phonogram

Answer 16

Ran into a similar problem with VS not discovering test methods. In my case I had the static keyword with the method, which I removed and it worked.

[TestMethod]

Before: public static void Test1()

After: public void Test1()

Fard

I'd really prefer if this was not here as this is about otherwise correct tests that can't be found in a particular instance of VS. I have a self-answered one re why an xunit test can't be discovered: #16215184. May I suggest you create a why cant my MSTest test be picked up (by VS if you want). (As you prob know, this particular concern does not even apply to xUnit which is another reason why, helpful as it is, your answer does not belong here) – Audwen

MSTest did not find my tests because the class access modifier was internal. – Sudatorium

Answer 17

There is one other reason that can cause Test Explorer not showing any tests, and it has to do with the new portable .pdb file format introduced with Visual Studio 2017 / for .NET Core which can break some VS tooling. (Background: See the bug report "Mono.Cecil causes OutOfMemoryException with new .csproj PDBs".)

Are your tests not found because of the new portable .pdb (debug symbols) format?

• Open the Output window.
• Change drop-down selection for Show output from to Tests.

• If you see output like to the following (possibly repeated once for each of your tests), then you've got the problem described in this answer:

  Exception System.OutOfMemoryException, Exception converting <SignatureOfYourTestMethod>
  Array dimensions exceeded supported range.
  

If yes, do this to resolve the problem:

• Open your test project's Properties (select the test project in Solution Explorer and press Alt+Enter).
• Switch to the Build tab.
• Click on the Advanced... button (located at the very end of that tab page).
• In the drop-down labelled Debugging information, choose none, pdb-only, or full, but NOT portable. It is this last setting that causes the tests to not be found.
• Click OK and clean & rebuild your project. If you want to be extra sure, go to your test project's output directory and clean all .pdb files before rebuilding. Now your tests should be back.

Taxation

Answer 18

In my case, I had 2 different test projects in the solution. Project 1 tests could be found, but Project 2 tests could not. I found that first Unloading the test Project 1, then closing VS > clearing my temp files > re-open solution > rebuild, allowed VS to discover my Project 2 tests.

I'm assuming something must be conflicting between the two test projects and this was the quickest way to get me up and running in a few minutes. The kinks can be worked out later :).

Obstruct

Answer 19

I tried most of the suggestions above and nothing worked. In my case, I'm on a team and tests were appearing for other devs for the same solution. So, I attempted just deleting my .vs folder, but no luck there either.

I ended up deleting my local folder entirely and re-cloning the repo. That solved it for me.

Manado

Answer 20

I was suffering from this problem for long times.

• I had about 100 projects different version was deployed in different server.

• Updating xunit from 2.2.0 to 2.3.1 was not a solution because build was failing in 2.3.1.

Then I just updated xunit.runner.visualstudio to 2.3.1 and everything started to work fine. I have used this command in my package manager console to updated my xunit.runner.visualstudio package

Get-Project ComapanyName.ProjectName.*.Tests | Install-Package xunit.runner.visualstudio -Version 2.3.1

Olwen

Answer 21

1. Close all Visual Studio instances
2. Go to %TEMP%\VisualStudioTestExplorerExtensions\
3. Delete specrun related folders
4. Try again

let me know, thanks

Kuehnel

Answer 22

I hope my answer will be helpful for some of you: In most of the cases when my unit tests were not discovered I had to change the the test class access modifier to public. When add a new class (Shift+Alt+C) the default access modifier is internal and most of the time I forget to change it.

Beady

This set of reasons, which will make them not work on anyone's machine anywhere (except TestDriven.net will half-run them) is covered under the question linked to in the OP: #16215184 – Audwen

Please don't add "thank you" as an answer. Once you have sufficient reputation, you will be able to vote up questions and answers that you found helpful. - From Review – Cauterize

Answer 23

The most common culprit for me has been Visual Studio trying to run the tests using a different architecture than the library it's testing. Unfortunately there are multiple places where it seems this can go wrong.

In VS 2017, try creating a Run Settings file, e.g. Default.runsettings in your test project. If your main lib is x64, the contents should be:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x64</TargetPlatform>
  </RunConfiguration>
</RunSettings>

Then choose this file from Test -> Test Settings -> Select Test Settings File.

Then, under Test -> Test Settings, Default Processor Architecture, choose the correct architecture again.

Be sure to Clean and Build the entire solution. You may need to close and reopen the Test Explorer window. Look for any additional errors in the Output -> Test window, for more clues about incorrect architecture types.

FYI additional Test Settings entries can be found here.

Monteiro

Answer 24

Happend to me when i took my first first walking attempts with IntelliTest in VS 2017.

Sometimes, when the test project gets auto-created by IntelliTest, the assembly reference to Microsoft.ExtendedReflection (...\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\Pex\Microsoft.ExtendedReflection.dll) is missing. When added, the generated Tests will show up in test explorer after recompile.

Bowden

Answer 25

Disclaimer: it is not about xunit with visual studio 2015, but Visual Studio 2017 with a UWP unit test application (MSTest). I got to this thread searching the same thing so maybe someone else will do the same :)

The solution for me was to update the nuget packages for MSTest.TestAdapter and MSTest.TestFramework. It seems that when you create a unit test app for UWP you don't automatically get the latest versions.

Voodoo

I'd suggest asking a self answered question as I did is the best way to sequester such info - feel free to copy paste my entire question and s/xUnit/MSTest/ if you think it makes sense ;) – Audwen

Answer 26

My problem was resolved by installing the nuget xunit.runner.visualstudio

Perforce

Answer 27

In my case I have multiple test projects in the same solution, and only one of the projects was not displaying the "Test Explorer"

I went to the "Manage Nuget Package for Solution" by right-clicking on the solution.

I noticed under the "Consolidate" tab there was some "Test" nuget packages that were out of sync between the projects. I clicked on "Install" and my missing tests showed up.

Poach

Answer 28

Here is the solution that worked for us. Not the best but maybe one can benefit.

Background:

• Our scripts were developed with VS 2013 and used NUnit VS Adapter 2.1..
• Recently we migrated to VS 2017 and when open the same solution - test wouldn't show in the Test Explorer

Upon Build we would see this message:

[Informational] NUnit Adapter 3.10.0.21: Test discovery starting
[Informational] Assembly contains no NUnit 3.0 tests: C:\ihealautomatedTests\SeleniumTest\bin\x86\Debug\SeleniumTest.dll
[Informational] NUnit Adapter 3.10.0.21: Test discovery complete

Solution (temporary):

• Uninstall NUnit Adapter 3.10...
• Install NUnit VS Adapter 2.1..

Now the Tests are shown.

Amalberga

Please extract your (at least seemingly) new question to its own post to make this a clear answer :) – Witchery

... Entitled "why is the NUnit TestAdapter v3 not seeing my NUnit v2 tests? and a) ping here b) an put a "see also <link>" at top (even if it is slightly tenuous), but I'd like this answer removed as it does not fit well with the xUnit v2 tests in the title. – Audwen

Answer 29

Also check if a completely empty app.config file (completely blank with absolutely no markup) is within the test project. This was the culprit in my case.

Bagger

Answer 30

In my case, I created a new "Solution Configuration" like shown in the image. So when I select my custom one as "Prod", it doesnt recognize TestMehods for some reason. Changing back to "Debug" solves the problem

Stake

Answer 31

I don't know if some of you also use JustMock, but I had to disable the profiler in VS 2017 for test detection to work.

Sanjay

Hmmm. If you turn it back on, does it immediately fail again? – Audwen

Yep. If I close the solution, turn on the profiler and get back in, test detection fails. – Sanjay

Answer 32

I had many projects of different type in my solution and I could not run the Xunit test project. I unloaded all of them except my Xunit project and then rebuild the solution the tests appeared in visual studio and I could run them.

Spall

Using Visual studio 2017 and after upgrading package to xunit.runner.visualstudio.2.3.1, Xunit tests appeared next to Unittests. – Spall

Answer 33

You need to update your all packages when you are move VS2015 to VS2017 for discover test in test explorer.

Shipmaster

Answer 34

I Cleared Temp, %Temp% and Prefetch. Then tried reopening VS and was able to find the test methods

Riha

Answer 35

I have test project A and B. Tests in Project A where discovered but the Discovery never stopped for B. I had to manually kill TestHost to make stop.

I did a lot of things this page describes even to the point that I'm unsure as to wheter this was the solution.

Now it worked and the thing I did was to open the Solution and NOT have the Test Explorer up. Instead I just checked the Output window for Tests and I could see the discovery process end and the number of test where equal to A+B. After this, I opened the Test Explorer and then both A and B where present. So:

Uninstall and Install the latest xUnit stuff correctly. Delete the %temp% as mentioned above, Add NuGet Package "Microsoft.TestPlatform.TestHost" Add NuGet Package "Microsoft.NET.Test.Sdk", restart but only check the Tests Output. If it works u'll see

Venial

Oh, and check the Test target Architecture. x86 or x64 and make sure project and references are inline with your choisce – Venial

Hm, not sure I buy the uninstalling and reinstalling packages or the need for Microsoft.TestPlatform.TestHost or Microsoft.NET.Test.Sdk but I appreciate the frustration, the documenting of stuff you did in order to reach the endline in your context (will +1 should I manage to verify this as a specific step that makes a difference) – Audwen

Can you mention your VS version in this ? While I'm trying to keep the question and my self-answer version-independent, I suspect anyone reading this and guessing whether it's worth a shot would benefit from that context being edited into your answer. – Audwen

I can add that today it DID NOT work at all!! It is VS 2017 Enterprise. I gave it up today. I unloaded the project and the test will not be run. There is probably something wrong with the project itself. Read somewhere it could be due to async tests in combination with exceptions (NotImplemented) maybe but I'm done with it. There's no valueable info.It just hangs on discovery and some times I have seen the test but not today. – Venial

That sound like a proper pain. If discovery is actually hanging (ie. Test window of Output panel is showing no completion and no errors), it may be useful to attach another copy of VS (via attach to process, Ctrl-Alt-P) to the vstest.discovery.exe host exe within which that takes place. However I suspect that there should be some form of timeout and have not ever heard of anyone actually doing something like this. I hope your problems get simpler some time soon :( – Audwen

Answer 36

Make your test class as public and add annotation as [TestClass]

Femininity

Please remove - this question is about xunit, and even if it mentioned the Xunit attributes, that's excluded in the question – Audwen

Answer 37

Right click on Test project and select Properties. Change Target framework property from 1.1 to something else (I used 3.1) and everything will run as 1.1 isnt covered anymore :P

Puton

Thanks, I will check it out as soon as I get the opportunity. If it works will let you know. – Meantime

Answer 38

Open Outputs -> Tests and see what the error is. In my case, I had this error message:

The framework 'Microsoft.AspNetCore.App', version '5.0.0' (x64) was not found.

After installing .Net SDK 5.0, tests worked immediately: https://dotnet.microsoft.com/download/dotnet/thank-you/sdk-5.0.402-windows-x64-installer

Disassemble

Answer 39

Make sure your project is not open as a "folder" instead, click the .sln file within the folder.

Once the project is opened using the .sln file, you should be able to build then subsequently run the xUnit tests.

Journalistic

Answer 40

It was that easy for me - the class which contains the test methods must be public. :)

Spleeny

This solution has already been posted on this page. Please don't add duplicates. – Convolvulaceous

Hi, I excluded this reason in at the start of the question - this one: #16215184 is a similar one about why it doesn't work for anyone. This question is about "why is in not working on my machine, it normally works" ?! – Audwen

Answer 41

check the type of test.cs files in property window and it is c# compiler. in my case i have accidentally changed it to the embedresource and faced this issue.

Denver

This would prevent it working on any machine (the OP excludes such reasons); such reasons are catalogued in #16215184 - can you place the answer there instead please? – Audwen

I agree, but this is what i faced in my scenario and none of them worked for me and finally realized that i had accidentally changed. i know this is very rare case but happened to me – Denver

Yes, but please log that as an answer to the other question linked in this question! It answers that question, it does not answer this. This question says "it works for everyone but be, what could it be". The other one says "my test wont work no matter what I do" – Audwen