I was hoping to run NUnit tests on my .Net 5 code and use the console runner to generate an XML output file.
It looks like console-runner doesn't work with .Net 5 and dotnet test can't pass command line arguments through to NUnit.
I was wondering - as a stopgap, how hard would it be for the NUnit code to check for a file and, if it exists, read the file to get parameters like one would pass to the console-runner on the command line? I'm thinking something super-simple like an .INI file or a .JSON file might do the trick. Perhaps the file should always be found in the same directory as the .DLL that contains the tests, maybe the file could have a designated name, etc, etc.
I'm hoping that the file-reading code could be written mostly independently of the existing NUnit code, and could be added into the code that parses the command line arguments (with the intention of removing this once console-runner works with .Net 5+ and/or dotnet test can pass real command line args through to NUnit).
Is this reasonable and desirable?
Edited To Add:
It looks like NUnitLite _can_ be run on .Net 5 programs and generate XML files (at least, it worked for my .Net 5 program, and it generates an XML file that looks ok at first glance). I'm leaving this edit here in case anyone else is looking to do the same thing I am.
I think dotnet test has a way to pass TestParameters through the .runsettings file - although can't see anything mentioned in the docs. @OsirisTerje - can you help? 馃檪
As far as I can tell from the code, one can use TestRunParameters -
https://github.com/nunit/nunit3-vs-adapter/blob/8a9b8a38b7f808a4a78598542ddaf557950c6790/demo/demo.runsettings#L18-L22. See e.g. nunit/nunit3-vs-adapter#251 for how to do this.
So I don't think we should do anything with this issue - except perhaps improve the documentation.
It looks like the .runsettings allows you to define parameters which your tests can then use.
I was suggesting that we could use a text file as a substitute for passing command line parameters (in order to pass those command line parameters through dotnet test - stuff like "write results to an XML file", etc).
Also - I got NUnitLite to handle my use case (runs on .Net 5, outputs results into an XML file) so I think I'm ok with what I've got.
Quick question though - is there a roadmap anywhere which helps clarify how long NUnitLite will be supported? I'm using it now but would love a sense of how long I can rely on it being part of the project (esp. with .Net 6, 7, 8, etc coming out in fairly quick succession)
Also - Thank you all very much for the super-quick reply, and the thoughtful, expert responses!
(Since NUnitLite seems to be working for me I'm happy to close this, or y'all can close it, or whatever :) )
I was suggesting that we could use a text file as a substitute for passing command line parameters (in order to pass those command line parameters through dotnet test - stuff like "write results to an XML file", etc).
I misread your question (or I blame Chris for confusing me with the word "TestParameters" 馃槃). Note that .runsettings allow you to set most of the parameters that the console runner accepts, see https://docs.nunit.org/articles/vs-test-adapter/Tips-And-Tricks.html for more information.
Quick question though - is there a roadmap anywhere which helps clarify how long NUnitLite will be supported? I'm using it now but would love a sense of how long I can rely on it being part of the project (esp. with .Net 6, 7, 8, etc coming out in fairly quick succession)
There is no roadmap for this, but I would guess that it will be around for a long time. The latest NUnitLite issue is actually to move it into the framework - nunit/nunit#3759
Most helpful comment
I misread your question (or I blame Chris for confusing me with the word "TestParameters" 馃槃). Note that .runsettings allow you to set most of the parameters that the console runner accepts, see https://docs.nunit.org/articles/vs-test-adapter/Tips-And-Tricks.html for more information.
There is no roadmap for this, but I would guess that it will be around for a long time. The latest NUnitLite issue is actually to move it into the framework - nunit/nunit#3759