Create a test trait to abstract repetitive UI checks/asserts

@Ambient.Impact: Nice improvement, I think this is good to merge. As I mentioned in ✨ Add support for ConfigEntityListBuilder config forms Fixed , let's also leverage this trait to test for the presence of the config enforce container on a variety of config forms, to cover the various cases ConfigResolver covers. I think this could reasonably go in on this issue/MR if we repurpose it a little bit, but if you prefer to create a new ticket for it, feel free :)

@spiderman That issue was actually the reason that prompted the realization that this would be a good time to implement this, so definitely agreed that we should use it every where we can.

If I really wanted to overengineer this, we could even centralize this check in the main module outside tests, so this lives right where we specify the structure of the container we place on forms, but that's for another time.

I've merged this current merge request and I think a separate follow up would make more sense since this just adds the trait to existing usage, while adding new checks feels like it should be a separate (but related) bit of work.

Re-opening this because we also need a couple of additional methods to assert whether or not a specific config is listed in the Config Enforce container, so that we can test for more specific things such as ✨ Expand ConfigResolver tests to cover all config types we support Fixed and 🐛 Plug-in based config not correctly identified on config forms (e.g. text editor/CKEditor) Needs review .

@Ambient.Impact: this looks great to me. Ship it!

Heck yeah!

Automatically closed - issue fixed for 2 weeks with no activity.