Well at least the OneTimeSetup on the actual test did not work, that is what i had.
I will check if it works with the fixture though tomorrow.
Still now 100% ideal, since this also would copy data that is not used if you run it from the VS Test Explorer. With a single test that is.
Cool.... if the OneTimeSetup didnt work, there is something you do in the file loading - but anyway , the setupfixture should do it for you. TestCaseSources are statics, so they can fool you if you access them too early. They should be doing things in a lazy manner, not in the ctor.
I also might try to use the proposed static constructor.
Oh now that is nifty :) i also could do the lazy thing and just copy the file when the test gets instanciated ... :)
The code i wrote to sync the server and local directory is split up in yielding commands that need to be executed in order to do the sync and an interpreter, so i think i should be able to enumerate the query in the TestCaseSource and wrap them in a Func with the deleted files calling Assert.Ignore
I am currently copying data in the test case source (not a good idea i know) and think that the data gets copied although the test is excluded due to it's category.
Heya all! I've have a question. I'm have 4 classes that generally do similar functionality, but for different types (specifically type converters toBool, toDec, toInt, toStr), except the core logic that does the type casting, the rest is really the same.
I'm trying to find a way to create a skeleton fixture that could get the type and a bunch of test case sources that I could run for each type. alas I'm not finding a way.
is it even possible?
I'm trying to find a way to create a skeleton fixture that could get the type and a bunch of test case sources that I could run for each type. alas I'm not finding a way.
is it even possible?
@tbragaf It can be that there is an issue with running on the UI thread - see nunit/nunit#3908. How are you executing the test? and is there any more information that just inconclusive?
@mikkelbu I am executing through rider IDE and the code is pretty simple... Just uncomment that commented line and the test doesn't run. I am also using mac OS and this environment of nunit in mac os seems not to allow running code on the UI thread like this.
using System.Threading;
using NUnit.Framework;
//[assembly: Apartment(ApartmentState.STA)]
namespace STATests
{
public class Tests
{
[Test]
public void Test1()
{
Assert.Pass();
}
}
}
I also tried with xUnit and the test runs fine but never runs on the UI thread
@tbragaf I did a little searching (I don't know much about this area), and I'm not sure if it is possible to run on the UI on mac OS at the moment, see e.g. https://github.com/nunit/nunit/issues/2917#issue-337606935.
Okay, I'm thoroughly confused with respect to the console runner. What framework versions are supported by the current stable version of the console runner? Are .NET Core/Standard tests supported by the current stable console runner? What about .NET 5.0/6.0 tests? If not the current stable console runner, is there another console runner that does support .NET Core/Standard and/or .NET 5.0/6.0 tests? I'm not willing to use NUnitLite, nor am I willing to use
dotnet test. My project uses an entirely different, non-MSBuild-based build system, and a separate console runner tool would be, by far, the best option to integrate with that build system.
@jimevans The stable version only works with .NET Framework. I don't know about any other console runners for .NET Core and for .NET 5.0/6.0 available at the moment. So your only options are (as you have discovered):
- nunitlite
dotnet test(and using the nunit-adapter)- TestCentric console runner when it is ready - TestCentric/testcentric-gui#831
or slight differences to that which are within the delta
has drivers for .Net Core 3.1 but you can make the tests run on .Net 5.0 or 6.0. However, they currently cannot target those runtimes.
by different test runners because it relies on the directory structure the runner itself creates. So...
- nunit3-console installed via nuget picks up any extensions you install from nuget
- nunit3-console installed via chocolatey picks up any extensions you install from chocolatey
- etc. :-)
I wish there were a single answer! As it is, it's best if you detail what your specific cases are.
@all I'd like to call attention to nunit/nunit-console#1045 which proposes eliminating the NUnit.ConsoleRunner.NetCore package.
If you're a user of that package, please comment... preferably on the issue itself, but feel free to ask questions here as well.
The NUnit.ConsoleRunner.NetCore package was developed at a time when the NUnit3 console runner (NUnit.ConsoleRunner)
was not capable of running .NET core tests. Now that that is no longer the case, maintaining two runners seems like an
unnecessary effort.
Hello, have a question.
I have lots of parameterized tests that use TestCaseSource.
All these tests have different categories, properties(smoke...)
For my reporting(ExtentReport) I want to tag tests with corresponding test categories, for that, I'm trying to access my categories via TestContext. In code it looks like:
var testCategories = TestContext.CurrentContext.Test.Properties["Category"];
But for my parametrized tests I don't receive any category. For non-parameterized tests, it works just fine.
Can someone help me with that? Any workaround?
1 reply
@CharliePoole I'm actually trying to solve assembly loading issues in tests https://github.com/nunit/nunit/discussions/4005
@shack05 yes, I'm using the first approach. Via TestCaseSource I'm passing test cards as objects so it's pretty generic and used across almost every test. For example, I have method AllFailedCards, as you can see it's to generic and might be used for tests with different categories, so I cannot specify particular category inside the method.
@mhotsiy The problem is that the
CategoryAttribute is on a parametric test and not on the test itself - so the category is on the parent of the test. Most users find this surprising - see e.g. nunit/nunit#1358 or nunit/nunit#548 - but this is how NUnit behaves at the moment. Hopefully, we can change this for version 4, but so far it has been unresolved for a long time.
I've spent most of the day trawling through endless combinations of google searches for anyone who has managed to get TeamCity to display NUnit results when being run via dotnet test ....
lol I found my post from almost a year ago :-P .. going to try that now (last year I just resorted to using the NUnit console runner directly rather than dotnet test)
so, going back to 2020, writing the test-results.xml file works, along with defining the feature step in TeamCity to read the xml files, but is there a way to have the console output "##" style work as be detected in TeamCity while the tests are running, similar to what happens when you run the tests directly with the nunit console runner
@nrjohnstone A bit late, but have you tried
TeamCity.VSTest.TestAdapter (source and documentation is at https://github.com/JetBrains/TeamCity.VSTest.TestAdapter)? Even though it has VSTest in it's name it also works with NUnit.
@Archana-N As far as I know the TestResults.xml are not uploaded as part of the appveyor build and we don't use appveyor's inbuilt testrunner -
https://github.com/nunit/nunit-console/blob/main/appveyor.yml#L12, so I cannot lead you to the test results. Why do you need the test results?
In the future perhaps we can upload them as part of the pipeline (I have not checked whether appveyor supports this)
https://github.com/nunit/nunit-console/blob/main/appveyor.yml#L12, so I cannot lead you to the test results. Why do you need the test results?
In the future perhaps we can upload them as part of the pipeline (I have not checked whether appveyor supports this)
Appveyor supports uploading test results. Have a look at https://github.com/fluentribbon/Fluent.Ribbon/blob/develop/appveyor.yml
@mikkelbu : It is to evaluate the OSS before standardizing throughout the organization. This is part of the regular process followed. Hence, I need the test results (if already available) to know the impact. I assumed all the build artifacts would be available for 30 days (as mentioned in the pipeline). It would be helpful if you can upload as part of the pipeline in future.
