feature(WorkspaceValidationTests): add possible to create workspace-wide tests

[DarkWeird]

Contains

Proof-of-concept Workspace-wide tests(a.k.a mega test)

There should be tests with validate assets/assets/loading/mechanics loading provided by engine. Possible Future - modules can provide tests, which will applicable to dependents (like API usage validation)

Currently using MTE as module. not works without it. Currently use JS as target module to test. just for demonstration purposes.

How to test

0. init workspace with JS and MTE (temporary)
1. gradlew :facades:WorkspaceValidation:test

Outstanding before merging

• [ ] MTE as Subsystem? It should be fine: will grants more possibles, remove optional module
• [x] provide mechanism for using modules as test's parameter for loading (like runs tryToLoadBehavior test across all modules)
• [x] remove specific module-related test.

[keturn]

Hmm, interesting, I need to think about it a bit more, but a few initial thoughts:

1. On moving MTE: Yes, see https://github.com/Terasology/ModuleTestingEnvironment/issues/39
   • Does MTE want to be a Subsystem? Not sure, but are some arguments in favor: https://github.com/Terasology/ModuleTestingEnvironment/issues/75#issue-1046546531 — it would be able to use the preInit/init/postInit hooks.
2. Why is this categorized under facades/?

[DarkWeird]

Does MTE want to be a Subsystem

Maybe i named it wrong. Not EngineSubsystem, but a some subsystem which provides additional functionality for modules.(MTE exactly provides test functions for module's tests) It cannot be library - too connected it with TS's engine.

Why is this categorized under facades/

I think that right semantically. Facade is something that runs engine and modules. (PC, Server, AWT, Ed etc) This test-related facade, which can runs test over whole module space.

[DarkWeird]

I have not yet reviewed the extraordinary stream pipeline of voluminous indentation.

This stream provides: 0. Module selection, then create tests per module

1. Setup as test per module ( a bit hacky. Setup provides asset manager via AtomicReference)
2. Asset list by type(2 types) per module.( A bit hacky, asset manager accessable only after (1) Then creates test per asset.
3. Append teardown per module

[DarkWeird]

@keturn

I have not yet reviewed the extraordinary stream pipeline of voluminous indentation. see_no_evil

Refactored :) Code can be reused for any other assets

[skaldarnar]

Some thoughts and notes on this as I was trying it out to help with the Behaviors/Pathfinding work:

• Crash Reporter opens up on failed tests
• runs a lot of tests (not sure what they are all about) which definitely need better names and descriptions

  23498 tests completed, 20 failed

• the 20 failed tests did not help me to figure out what exactly is wrong ... :thinking:

[DarkWeird]

Crash Reporter opens up on failed tests

Mte-related known issue...

runs a lot of tests (not sure what they are all about) which definitely need better names and descriptions 23498 tests completed, 20 failed

If you runs it from idea you saw it better. It have structure..

I have Synthetic tests for setup mte and teardown mte there. Mostly fails related with invalid assets/misconfiguration classes will in setup part.