In the previous section we looked at Kernel tests and said that they are basically integration tests that focus on components rather than interactions with the browser. In this section, we'll go one level up and talk about the fully-fledged Functional tests, otherwise called browser tests (from the name of the base class we need to extend).

Functional tests in Drupal 8 use a simulated browser (using the popular Mink emulator) that allows users to click links, navigate to pages, work with forms and make assertions regarding HTML elements on the page. What they don't allow us is to test JavaScript-based interactions (see the next section for those).

In Drupal 7, Functional tests were the most common type of tests used, most classes extending from Simpletest's WebTestBase class. But in Drupal 8 we have the DrupalTestsBrowserTestBase class which is integrated with PHPUnit like the ones we've seen before. And the base class contains loads of methods both for asserting things and shortcuts to performing Drupal (and web) related tasks: creating users, entities, navigating to pages, filling in and submitting forms, logging in, and so on. And just like before, each test (class method), runs in isolation so things like content and users cannot be shared across multiple tests but would have to be recreated (perhaps using the setUp() method as we've already seen).

Browser tests perform a full Drupal installation with a minimal number of modules (using the Testing installation profile). This means that we can specify to install other modules as well, and the schema for these also gets installed. Moreover, it's also important to understand that the resulting installation has got nothing in common with our current development site. Any configuration we need, we have to create. There are no users, no content and no files. So it is a brand new, parallel installation, that runs for the duration of one single test and gets cleaned up as it finishes.