Make NuGetTest updates better (OSOE-816)

[Piedone]

This is not a fully planned out suggestion, more of a problem statement and opener to think together.

When you change an OSOCE project today, you don't have to publish an alpha NuGet package. This is OK, since not every change warrants an alpha due to it being used in another NuGet solution (or things like docs or sample changes don't need a NuGet release ever).

However, this results in versions used in the NuGetTest package gradually going out of date. That is, until an OC upgrade requires an update to every project, when all potential breaking changes will arrive at once, and you have to fix the NuGetTest solution. Or a project's NuGet publish may fail as well, e.g. due to incomplete project-package references, or something breaking due to the Node build.

A couple of ideas on how to tackle this:

• Require a NuGet release before approving every submodule PR, if the changes in that PR affect the NuGet package (excluding e.g. the mentioned samples or docs changes). However, this is a chore.
• Run a NuGet package creation, but without publishing to NuGet.org, for every submodule commit, kind of like a CI build. This would at least prevent introducing NuGet publishing errors. - This is now done by Automatically check baseline package validation during review (OSOE-864) GitHub-Actions#359.

Related issues that might help here: #703 and Lombiq/GitHub-Actions#70.

Jira issue

[Piedone]

With Lombiq/GitHub-Actions#359 this is less of an issue: if a project needs to change due to Lombiq dependencies (like changes in UI Testing Toolbox of Helpful Libraries) then it'll fail NuGet validation.

#703 will make it more apparent if the NuGetTest solution's dependencies need to be updated, including Lombiq ones.

So, what remains as not just a manual task but also something that needs to be remembered, is adapting to code in NuGetTest itself to Lombiq package changes. However, most of the code there is in the tests.

[Piedone]

However, most of the code there is in the tests.

And because of that, the real solution here would be probably to share the tests between the two solutions, i.e. Lombiq.OSOCE.Tests.UI and possibly Lombiq.Tests.UI.Samples. There are two challenges here:

• In NuGetTest they should reference NuGets instead of projects. This seems doable.
• UI tests need to reference the web project's Program, what we usually do from the test project's central UITestBase as public class UITestBase : OrchardCoreUITestBase<Program>. I don't think we can get around this with standard C#, without having to have duplicated test classes. Source generators could be a solution: then, each module's test project could generate their test classes, instead of just having extension methods to call from tests (but that would remove the option to customize what happens before/after them).