Identify which browser tests should be running the language settings form and add a @covers to document it

These are the ones which I think are testing the form:

content_translation/tests/src/Functional/ContentTranslationEnableTest.php
content_translation/tests/src/Functional/ContentTranslationDisableSettingTest.php
content_translation/tests/src/Functional/ContentTranslationUISkipTest.php
content_translation/tests/src/Functional/ContentTranslationSettingsTest.php

I note in passing that there appears to be no coverage in language module of the ContentLanguageSettingsForm *without* content_translation's form alterations. Is that something that should be fixed as side issue?

Tests that run the form in a test method rather than setUp():

- ContactLanguageTest - has no business testing this form, it doesn't belong to this module!
- ModerationFormTest - same
- ContentTranslationContextualLinksTest - says it's using the form 'This tests that caches are properly invalidated' but that surely belongs in a test with a more accurate name.
- ContentTranslationOperationsTest - needs fixing
- ContentTranslationStandardFieldsTest - not sure. The code makes it look like it's checking the standard profile is correctly set up for translation. But the docblock 'Tests that translatable fields are being rendered' suggests it's testing the form. But if that's the case, it shouldn't use the expensive to install standard profile, but test modules instead.
- ContentTranslationSyncImageTest - says " Check that the content translation settings page reflects the changes performed in the field edit page." - but weird place to do that in. Future refactor?
- ContentTranslationUntranslatableFieldsTest - fix
- EntityReferenceFieldTranslatedReferenceViewTest - fix
- ImageOnTranslatedEntityTest - fix
- LanguageConfigSchemaTest - fix
- MenuUiNodeTest - fix. Test comment says 'Use a UI form submission to make the node type and menu link content entity translatable.' but that's just silly.
- NodeTranslationUITest - fix
- PathContentModerationTest - fix
- PathLanguageTest - fix
- SearchMultilingualTest - fix
- DisplayFeedTranslationTest - fix
- PathWorkspacesTest - fix

Love this, thanks for getting it going! Hope to have time to help sometime "soon".

Going to set this to NR - the list in #4 needs review and approval before doing the work.

Think could be added too

PrivateFileOnTranslatedEntityTest
FileOnTranslatedEntityTest

Thanks!
Updated the IS to add the analysis so far, to make reviewing easier.

So I believe the list you got is good.

Now that is a lot so not sure if breaking it up would be quicker in the long run.

Made a MR which adds @covers tags to the tests which are actually testing the form.

Once this is merged, we can file follow-on issues to convert all the other tests which use this form to use API calls instead.

Tests all green so the @covers seem good.

Tagging for followup after merged.

+1 on baby steps to annotate these tests, and then follow through with converting other tests to use API calls in other issues.

My one very minor gripe is that @covers has a specific meaning for PHPUnit, such that all the coverage in a coverage report for that test will be filtered so it only contains that class or function. So this is a little bit of an abuse of the annotation, but is also completely reasonable for this process.

Some of these tests could likely be converted to KTB, but that's another meta for another day.

Very curious how the determination was made per test... Is there some magical regex or other methodology to generate a list like this? We could apply it to other settings forms, in order to find places to convert form-fill actions to API calls.

> Some of these tests could likely be converted to KTB, but that's another meta for another day.

I've got my eye on that sort of thing too! Functional tests which just check the page content for a simple string could be done as kernel tests. But we need a way to write the responses to HTML files for debugging and development.

> Very curious how the determination was made per test... Is there some magical regex or other methodology to generate a list like this?

I just did a search for drupalGet('PATH') in all files whose name matches '/Functional/'.

I don't think I managed to find a way to refine it to look specifically in the setUp() method. But that is a good heuristic - we could potentially teach it to DrupalRector. It's not comprehensive though - lots of tests to setup-ish things in their test methods.

Committed a55e653 and pushed to 11.x. Thanks!

I'm working my way down the list filing issues for the tests to fix.

Setting this issue to be a child of the meta.

All done! Phew!

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