The second Functional test we will write should test the salutation override form itself. In the previous one, we interacted with the configuration API directly to make changes to the configuration value. Now we will see if the form to do so actually works. But since we can reuse quite a lot from the previous test, and they are very closely related, we can add it to the same class:

/**
 * Tests that the configuration form for overriding the message works.
 */
public function testForm() {
  $expected = $this->assertDefaultSalutation();
  $this->drupalGet('/admin/config/salutation-configuration');
  $this->assertSession()->statusCodeEquals(403);
  $account = $this->drupalCreateUser(['administer site configuration']);
  $this->drupalLogin($account);
  $this->drupalGet('/admin/config/salutation-configuration');
  $this->assertSession()->statusCodeEquals(200);
  $this->assertSession()->pageTextContains('Salutation configuration');
  $this->assertSession()->elementExists('css', '#edit-salutation');

  $edit = [
    'salutation' => 'My custom salutation',
  ];

  $this->drupalPostForm(NULL, $edit, 'op');
  $this->assertSession()->pageTextContains('The configuration options have been saved');
  $this->drupalGet('/hello');
  $this->assertSession()->pageTextNotContains($expected);
  $this->assertSession()->pageTextContains('My custom salutation');
}

We start this test, in the same way, asserting that the hour dependent message is shown. This also proves that each test runs in its own independent environment and changes to the configuration in one test has no impact on the other. They all start with a blank slate.

Then we navigate to the configuration form page and assert that we do not have access. For this we use the statusCodeEquals() assertion method to check the response code. This is good because we need to be logged in with a user that has a certain permission.

So we create a new user account using the handy drupalCreateUser() method whose first parameter is an array of permissions the user should have. We can then use the resulting User entity with the drupalLogin() method to log in. Under the hood, this navigates to the user login page, submits the form and then asserts that everything went well. Now we can go back to the configuration form page and should have access-- something that we also assert. In addition, we assert that we have the page title and that we have the salutation text field HTML element on the page. We do so using the elementExists() method, using the CSS selector locator as we had done in the previous test. Again, check out WebAssert for all sorts of assertion methods that help you identify things on the page.

Now it's time to submit the form and override the salutation message. And we do this with drupalPostForm() whose most important parameter is an array of values to fill in the form elements, keyed by the name parameter of the individual form HTML element. In our case, we only have one. Do check out the documentation of this method for more information on all the things you can do with it. Once the form is submitted, the page will reload and we can assert the presence of the confirmation message. And finally, we can go back to the /hello path and assert that the old message is no longer showing but the new overridden one does so instead.

Running the test class again should now include this new test as well and everything should be green. And noticeably much slower as two full Drupal installations are done. In the next section, we'll bring JavaScript into the picture so that we can also test the more dynamic browser integrations. But already you can notice that due to performance hits, Kernel tests are much faster to run if you don't need to interact with a browser.