search

TestCentric / testcentric-engine

Test engine that loads and runs tests for TestCentric
MIT License
0 stars 3 forks source link

Engine Platform Support #22

Closed CharliePoole closed 1 year ago

CharliePoole commented 4 years ago

NUnit Compatibility Issue

Category: Platform Support Visibility: Users Resolution: Resolved: Both will support .NET 4.0 and .NET Standard 2.0.

Description

The TestCentric engine is built for

The NUnit engine is built for

ChrisMaddock commented 4 years ago

See https://github.com/nunit/nunit-console/issues/770 for the NUnit Engine discussion here.

@CharliePoole - can you clarify what the TestCentric GUI currently targets, is it .NET 4.0, or is it later? This would be an incompatibility vs my personal intentions for v4 of the NUnit Engine (which are all open to discussion!) - as discussed https://github.com/nunit/nunit-console/issues/770.

As a means of resolving that, would the TestCentric team be willing to package the GUI as a self-contained application, and remove the reliance of an installed framework? My personal opinion is that's the best way to package Desktop .NET applications now, and would also resolve this incompatibility.

CharliePoole commented 4 years ago

@ChrisMaddock You're asking about the GUI itself rather than just the engine?

The GUI is currently targeting .NET Frameowrk 4.5. The TC engine targets .NET 4.0 and .NET Standard 2.0. TC engine.core targets .NET 2.0, .NET 4.0, Net Standard 2.0, and .NET standard 1.6.

Anyway, I wasn't thinking about the GUI targeting as a source of incompatibility, only (possibly) the engine. Do you disagree? itself.

As far as a self-contained application, I had not been thinking of that. I was planning on adding a .NET Core implementation and eventually migrating to .NET 5. It seems like our audience is developers, who will always have one or the other platform installed. Do you think I'm missing something?

ChrisMaddock commented 4 years ago

My reason for asking about the GUI, is that one of the suggestions I made on the related NUnit issue was about dropping support for runners targeting .NET 4.5 and earlier. This bit:

The second change would mean that we would be dropping support for test runners targeting .NET Framework 2.0-4.6.0.

It seems like our audience is developers, who will always have one or the other platform installed. Do you think I'm missing something?

My opinion is that self-contained offers us a big opportunity to move forward faster in future. Agree your users would likely have .NET 4.5 etc installed now, but what about in five/ten years time - how long are you committing to support .NET 4.5? This is one of the main reason the NUnit Console is still limited to targeting .NET 2.0 - and something where we have a good opportunity to change here, while maintaining test running support. Self-contained means we don't have to restrict the platform we build on at all, as there's no pre-requisites for the end user.

CharliePoole commented 4 years ago

If by support, you mean "running tests under" I don't plan on dropping support for .NET 4.5 or even .NET 2.0 for that matter.

I thought we were talking here about the engine - i.e. the primary nunit.engine assembly - which doesn't determine what testing platforms we support but what host platform is needed for the runner. (Maybe we need some clearer language to make that distinction.)

Anyway, I expect the primary engine to support .NET Framework 4.5 (or higher, of course) and .NET Core 3.1 in the short term (2 years) and .NET 5.0 in the long term.

For test execution support, we depend on the agents, the engine.core and whatever platforms are present in the user environment. If we stop running in process, then the two kinds of support will no longer be inked.

So, all that said, are you talking about self-contained agents or the runner itself?

ChrisMaddock commented 4 years ago

The runner itself is my concern. We're in agreement that we will continue to aim to run tests on older platforms.

I would be suggesting that runners, such as the TestCentric GUI, should be built for a platform which supports self-contained deployment, and therefore the engine could target a higher level framework with no impact on end users.

CharliePoole commented 4 years ago

Maybe this is two issues... runner and agent?

I agree with what you're saying about the runners... people can just create runners that target the platforms supported by the (top-level) engine. If they want to reach the widest audience, they'll make their runners self-contained, but that's up to them.

Should we stop talking about what platforms each engine now supports and deal with what we plan to support? It's beginning to sound like we are converging to the same set of platforms.

ChrisMaddock commented 4 years ago

Yes, ok. 🙂

As per https://github.com/nunit/nunit-console/issues/770, I (personally and currently) would like the v4 NUnit Engine to support:

Runners that wish to run on older platforms, such as the NUnit Console, should achieve this via self-contained deployments.

I will say I'd like all the above to be kept under revision as we develop. Key issues I'm concerned about are the ongoing cost of supporting older platforms, and changes to the .NET ecosystem as we develop.

CharliePoole commented 3 years ago

@ChrisMaddock I think we can consider this resolved since 1.6 support will be removed from NUnit.

CharliePoole commented 3 years ago

@ChrisMaddock I just realized that NUnit has a netcoreapp3.1 engine so maybe this isn't yet entirely resolved. I'm talking about the engine assembly here, not the agents. The GUI uses a core 3.1 exe with a netstandard 2.0 engine. IOW it's not a user-level incompatibility but an internal one.

CharliePoole commented 2 years ago

Transferred from testcentric-gui issue 583

CharliePoole commented 1 year ago

We are no longer attempting to maintain compatibility with NUnit.