-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature(WorkspaceValidationTests): add possible to create workspace-wide tests #4949
base: develop
Are you sure you want to change the base?
Conversation
Hmm, interesting, I need to think about it a bit more, but a few initial thoughts:
|
Maybe i named it wrong.
I think that right semantically. |
…E-related test(for reworking)
… (prefab and behavior)
…est. don't run modules without behavior asset,override or delta
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have not yet reviewed the extraordinary stream pipeline of voluminous indentation. 🙈
Set<Name> moduleIds = temporary.getRegistry() | ||
.getModuleIds(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I have been trying to deprecate ModuleManager#getRegistry, because for the most part, other things being able to mess with the registry that ModuleManager is responsible for managing is bad for business.
Here you are using it to get all the modules in the current workspace. We could add a method to return this sort of read-only collection of module IDs, that would be pretty safe.
I'm guessing the other use case we have for wanting to see all the workspace's modules is the Advanced Game Setup screen where you pick which modules to activate. That uses a lot more than just the ID... I haven't looked at it to find out what interface it really wants.
void resolveAndLoadPairModules(ModuleManager moduleManager, Name moduleName1, Name moduleName2) { | ||
moduleManager.resolveAndLoadEnvironment(moduleName1, moduleName2); | ||
Assertions.assertNotNull(moduleManager.getEnvironment()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you confirmed this can actually fail? I'm wondering because of Terasology/ModuleTestingEnvironment#69
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, i cannot.
I tried to break one dependency.. but then gradle fail to resolve dependencies...
I don't know how to break dependency without breaking gradle resolution...
|
||
} | ||
|
||
public static class EnginesAccessor extends Engines { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's going on here? Why do we have a subclass that doesn't actually have any custom behavior? 😰
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is special temporary magic for accessing protected methods. ;)
Engines is nice enough, but i cannot access to EngineCleaner
This stream provides:
|
…mpose functions and provide comment strings.
…etTesting#template` can be reused for any tests.
Refactored :) |
Some thoughts and notes on this as I was trying it out to help with the Behaviors/Pathfinding work:
|
Mte-related known issue...
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. |
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)
How to test
gradlew :facades:WorkspaceValidation:test
Outstanding before merging
It should be fine: will grants more possibles, remove
optional module
tryToLoadBehavior
test across all modules)