I'm still against this, as said in#21780 we shouldnot add the extension overhead on all base tests, so this should live in a specific type test case likeValidationTypeTestCase.

The issue with a separate class, is that you can't add more core extensions, as each one will need a separate class then, which makes extending the classes or using multiple core extensions difficult.

In terms of the overhead, I don't think that is really an issue. The overhead is so small per test that the impact would be negligible

I understand your concerns, let me try again to explain why I suggest another way to solve this.

The issue with a separate class, is that you can't add more core extensions, as each one will need a separate class then, which makes extending the classes or using multiple core extensions difficult.

It should not be that difficult to call the parent, is it? Or maybe anExtendedTypeTestCase with all core extensions preloaded could be an idea?

In terms of the overhead, I don't think that is really an issue. The overhead is so small per test that the impact would be negligible.

The overhead is not only about performances even if it impacts every field of every form, which indeed could be negligible in tests, but about the context, all core type tests extend this class, that means we cannot test them with the minimum of code necessary to run them anymore, and IMO we miss then the purpose of unit testing. Testing the core extension should not imply to load the validation one, it should not be tied to it, to avoid side effects, that's what we need in unit testing.

Let's imagine we follow your idea, and now want to add the CsrfExtension because in most applications this extension is enabled too, almost all core tests would fail because the token field is not submitted unless defining the related option to false.

I agree that the validation extension has the singularity to deeply test form errors, but still moving it to another base type test makes much more sense to me, that's why I'm suggesting to do it instead.

Anyway thank you for your contributions, I'm not "against" solving your issue, I'm just worrying about how we should do it.

Thanks for this info, it makes much more sense now.

It should not be that difficult to call the parent, is it

The problem is not calling the parent. The problem is if you have aValidatorExtension,DoctrineExtension,CsrfExtension etc, and your form uses options provided by all the extensions, but they all live in separate classes. So you will need to extend one class, while manually registering the other extensions for your forms not to break.

Or maybe an ExtendedTypeTestCase with all core extensions preloaded could be an idea?

That could also work.

I played a bit with a different approach, to use traits instead of classes.
The trait would expose a single method (E.GgetValidatorExtension), then in the baseTypeTestCase class we can check if the trait is added to the current class, and if it is we can register the extension just by calling the method.

The benefit in this is that you don't have to load all the extensions in the base test case, and if someone wants the validator extension in their test, they only have to add ause ValidatorExtensionTrait to their test class which then automatically registers the extension.
This can then be done for all core extensions, where you only need to add the traits you are interested in.

What are your thoughts on this approach? I have a working POC available that I can push to this PR if you want to have a look at the implementation.

It may be a good idea, of course you can push it so every one can review :).

Changes pushed. It's just a POC, so I just want to get feedback on the idea. If everyone is happy with the approach then I'll finish the implementation

LGTM

The trait is now missing the tearDown (or maybe a tearDownAfterClass?) to set the validator property tonull.

tearDownAfterClass added to the TypeTestCase class

Can't usetearDownAfterClass since it's static, so I addedtearDown instead