Installer tests fail if contrib driver hides database credentials form fields

@mondrake: Is it possible to add testing for this?

If we cannot create testing for this then it must be very good documentated. In the patch and linked to this issue. Can you add screenshots/browser output with what good wrong. We need to make very clear why the code change is needed and hopefully make sure that somebody does not undo the change by eccident.

I have found a way to test this patch. In #3128699: Testing issue for pgsql_fallback is work being done to make the PostgreSQL fallback driver testable with Drupal core. Part of the current patch is:

diff --git a/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php b/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php
index 5728e62bc4..5aab4e5205 100644
--- a/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php
+++ b/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php
@@ -507,6 +507,7 @@ protected function installParameters() {
     $connection_info['default']['prefix'] = $connection_info['default']['prefix']['default'];
     unset($connection_info['default']['driver']);
     unset($connection_info['default']['namespace']);
+    unset($connection_info['default']['autoload']);
     unset($connection_info['default']['pdo']);
     unset($connection_info['default']['init_commands']);
     // Remove database connection info that is not used by SQLite.

When I remove this part of the patch the testbot fails with 69 extra fails. See #3112735-90: [IGNORE] testing issue.
When I then add the patch from this issue, all those extra failures are fixed. See #3112735-89: [IGNORE] testing issue.
For me this is "prove" that the patch works.

All the changes in the patch looks good to me.
For me it is RTBC.

@mondrake: Thank you for you work on this issue!

+++ b/core/tests/Drupal/FunctionalTests/Installer/InstallerTestBase.php
@@ -239,7 +240,21 @@ protected function setUpProfile() {
    */
   protected function setUpSettings() {
-    $edit = $this->translatePostValues($this->parameters['forms']['install_settings_form']);
+    $temp_edit = $this->translatePostValues($this->parameters['forms']['install_settings_form']);
+
+    // Ensure that the fields to be edited actually exist on the form.
+    $assert_session = $this->assertSession();
+    $edit = [];
+    foreach ($temp_edit as $name => $value) {
+      try {
+        $field = $assert_session->fieldExists($name);
+        $edit[$name] = $value;
+      }
+      catch (ElementNotFoundException $e) {
+        continue;
+      }
+    }
+
     $this->submitForm($edit, $this->translations['Save and continue']);
   }

$edit was used in drupal_get_form() (via $_POST['edit']) a long time ago, but it's not (or shouldn't be) in common usage any longer. Could we change both $edit and $temp_edit to something more descriptive? I tried to think of them and couldn't though...

Maybe $form_values and $form_values_to_submit?

Updated patch as suggested in #16.

I think this fix is being done in the wrong place. It feels as though \Drupal\Core\Test\FunctionalTestSetupTrait::installParameters() needs to get the correct params for the form. Perhaps we need to call \Drupal\Core\Database\Install\Tasks::getFormOptions() here and make sure we're doing the right thing. Or we need so new method on the db connection to get install settings.

But the current solution has the downside of hiding errors if installParameters() sets something up incorrectly.

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because I think that the direction @alexpott provided in #20 should be sufficient to fix.

I changed the issue summary proposed resolution to reflect this.

I tried to address #20.
No interdiff as it's a completely different code (different file and approach).

Last patch had some failures.

For resolving such failure need to create a concrete subclass that extends the abstract Tasks class, and then instantiate the subclass instead of the abstract class directly. updating the patch and Interdiff along.