Merge NUnitLite into the Framework

[rprouse]

The NUnitLite project is fairly small and is tightly coupled to the framework, so to me it makes sense to pull the classes into the framework giving people an easy option to make their tests self-executable.

I propose;

• Merge NUnitLite into the framework for the 4.0 release
• Drop the test runner, if you want to execute your tests outside of the engine/console, make them self executable
• Document how to make your tests self-executable by adding a Program.cs with a main function.
• Update the existing 3.13.1 NuGet listing to indicate that it is deprecated for 4.0
• Remove --teamcity and associated code. Anyone running in TeamCity will need to use the console.

[mikkelbu]

I think this makes sense. So I'm for this change.

[stevenaw]

I think I noticed some duplication today between the framework and NUnitlite projects. In theory, this could also help deduplicate some code.

[ChrisMaddock]

I like all your ideas, Rob.

One thought on NUnitLite's command line - it currently shares some of the same options as the console, but with subtly different behaviour, as changes made to the console haven't been backported to NUnitLite.

Would v4.0 be a good opportunity to simplify the NUnitLite command line options to only those which are provided by the framework itself, and remove the features which are implemented separately but duplicate Console features? Bit of an "overall NUnit ecosystem" discussion - but my view is NUnitLite should be the simplest way to run tests, and for any additional features users should be looking to the console or dotnet test. Maintaining three different command line runners across the organisation doesn't seem ideal - although aware that my involvement with the console maybe makes me biased here! 😄

From a quick scan down the docs, here's a list of args I think should be removed/revised for better consistency: --params (either remove or make consistent with --testparam) --timeout (re: v4 console changes, either remove or make consistent) --result spec (Currently different implementations and options available. Suggest NUnitLite removes spec functionality and allows filename only for single result format. At the least we should remove the nunit2 result format!) --explore spec (As above, suggest remove spec option and allow output to console only) --labels (inconsistent options with console, suggest remove) --teamcity (???)

[rprouse]

Would v4.0 be a good opportunity to simplify the NUnitLite command line options to only those which are provided by the framework itself, and remove the features which are implemented separately but duplicate Console features? Bit of an "overall NUnit ecosystem" discussion - but my view is NUnitLite should be the simplest way to run tests, and for any additional features users should be looking to the console or dotnet test.

Great minds think alike. I was considering the same thing 👍🏻

[oznetmaster]

That would be the correct approach if console/engine worked between different machines and different platforms.

Currently, NUnitLite with the TCP interface (written, I believe, by @CharliePoole ), which I support to run both Windows CE/Compact Framework and Linux tests on a "test" machine remotely from a Windows 10 PC, works wonderfully.

Console/engine does not support that environment, as far as I know.

Until console/engine can run tests remotely across machines and platforms, I think the NUnitLite should remain separate. Once console and engine have been extended to run in a mixed remote machine/platform environment, then merging NUnitLite into the framework makes sense.

[rprouse]

When working on this, consider #1534