Add automated tests to Default Admin

I added a FunctionalJavascript test in #3619127: Forms sidebar doesn't open with error links from Inline Form Errors module that operates the advanced sidebar on node edit forms with the Navigation module enabled.

FTR the theme does have some tests already.

I'm adding a functional JS test for vertical tabs in #3604037: Indicate that grouping elements have child element errors for UX and a11y.

I saw that #3582093: Convert Unit and Kernel tests that use Claro to Admin adds a kernel test for vertical tabs, but since Default Admin has a JS theme function (that #3604037: Indicate that grouping elements have child element errors for UX and a11y is currently breaking), a JS test would be good also.

Do we know more specifics on what exactly do we need tests on?

@gábor hojtsy I have added a broad list of required tests in the IS and intend to start working on the first two just now.

The first MR covers kernel and functional tests. Building them also discovered 3 bugs in the theme that I resolved too as part of the same MR. The one failing test is a random one that also sometimes fails elsewhere.

There are a few more issues that I found:

• PreprocessHooks::lazyToolbarUserPicture() calls toolbarUserPicture(), which does not exist; there is no toolbar_user_picture theme hook in core.
• PreprocessHooks::preprocessBlockContentAddList() and templates/admin/block-content-add-list.html.twig target the block_content_add_list theme hook, which no longer exists; /block/add renders entity_add_list.
• Settings::overriddenSettingByUser() builds the warning as a plain string, so Twig escapes the markup.
• Settings::setAll() and clear() dereference a NULL userData after the fallback.
• Helper::isActive() returns early without caching.
• templates/system/system-themes-page.html.twig emits the <h3> id twice.
• FormHooks::formAfterBuild() sets data-sticky-form-selector to an already prefixed value.
• FormHooks::formSystemModulesAlter() sets #module_package_listing, which no default_admin template reads.
• Helper::isContentForm() reads an unset callback_object for a FormState without a form object.
• defaultAdminAutocompleteTest.js is tagged only core; AdminBlockFilterTest is grouped only block; FileFieldWidgetAdminThemeTest has a stale @see AdminHooks->fileAndImageWidgetHelper().
• The per-user theme settings add no cache context; the pages the tests assert on are uncacheable because they carry forms, but a form-less admin page could serve one user's overrides to another.

Shall we address them here as well? I would recommend this in light of the tight schedule.

From the IS:

Visual regression tests. However, testing against former Gin doesn't make much sense, as default_admin has diverged from it quite a bit. But VRTs should help us moving forward by defining a reference now, against which we can test later.

I don't believe core has the capability to do visual regression tests. I vibed a DDEV plugin that can do it at https://github.com/mherchel/ddev-drupal-admin-vrt. But even to get decent coverage I have to install https://www.drupal.org/project/theming_tools and https://www.drupal.org/project/form_style. I don't know if it's feasible to add this to core (and it's definitely out of scope of this issue)

OK, this is now ready for review. Just saw that @gábor hojtsy has already changed the status accordingly, which is fine. I went through it myself once again this morning, and it looks good to me.

Please bear in mind, this is the first time I wrote such comprehensive tests, and I may have overreached. On the other hand, getting too much with tests is almost never possible. But yes, I have used AI to get this done, still it took me almost 3 full days.

This MR is way too large to review. There are several removals and changes at the top that don't seem related to tests. Then when I started looking at the tests a lot of them are very tightly coupled to the implementation - unit testing that a hook implementation adds a specific key to a form somewhere isn't really very useful, integration type tests that test the end result of the full page feel like a better option.

> getting too much with tests is almost never possible

I disagree. If your tests are tightly coupled to your implementation then it all becomes brittle; changing anything about the implementation means you also have to change the tests to match, and that shouldn't have to be the case.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.