use Drupal\KernelTests\Core\Entity\EntityKernelTestBase;
final class PostBuilderTest extends EntityKernelTestBase {
}
```
As it's a Kernel test for a Builder class, place it within a `Kernel/Buider` directory and the equivalent namespace.
## Testing the PostBuilder
Instead of writing test methods starting with `test`, you can also use an `@test` annotation or, in more recent versions of PHPUnit, a `#[Test]` attribute. This, with snake-case method names, is a popular approach as it can be easier to read.
Just be aware that if you write tests this way and don't add the annotation or attribute, the test won't be executed.
Let's start by testing the existing functionality within `PostBuilder` by verifying it returns published and unpublished posts.
Create these tests, which should pass by default as the code is already written:
In both tests, we create a new post node with `PostBuilder`, set a title and the appropriate status, get the post and assert it's in the correct state.
To verify the tests are working correctly, try changing some values in it and `PostBuilder` to see if it fails when expected.
## Tagging posts
Next, create a test for adding tags to a post.
It should be mostly the same as the others, but instead of an assertion for the published status, try to use `var_dump()` to see the value of `field_tags`:
> InvalidArgumentException: Field field_tags is unknown.
Why is this if `field_tags` is a default field that's created when Drupal is installed?
The same as users and content, the new Drupal instance is created for each test, which won't have your existing fields, so, in the test, you need to install the required configuration.
## Creating a test module
To have the required configuration available, it can be added to the `atdc` module.
Any configuration files within a `config/install` directory can be installed, although if a site already has `field_tags` defined, we don't want to cause a conflict.
The convention is to create a test module that will only be required within the appropriate tests and to place the configuration there.
To do this, create a `web/modules/custom/atdc/modules/atdc_test` directory and an `atdc_test.info.yml` file with this content:
Because of adding `hidden: true`, it won't appear in the modules list in Drupal's admin UI and avoid it being installed outside of the test environment.
Within the module, create a `config/install` directory, which is where the configuration files will be placed.
## Creating configuration
But how do you know what to name the configuration files and what content to put in them?
Rather than trying to write them by hand, I create the configuration I need, such as fields, within a Drupal site and then export and edit the files I need.
To do that for this project, as I'm using the PHP built-in web server, I can use Drush to install Drupal using an SQLite database:
Note: if you need Drush, run `composer require drush/drush` to install it via Composer.
If you have a database available, you can use that, too.
Once Drupal is installed and the configuration has been created, you can go to - /admin/config/development/configuration/single/export and select the configuration type and name.
The filename is shown at the bottom of the page, and you can copy the content into files within your module.
The `uuid` and `_core` values are site-specific, so they can be removed.
To add `field_tags`, you'll need both the field and field storage configuration.
These are the files that I created in my module based on the field I created.
Exception when installing config for module atdc_test, the message was: Field 'field_tags' on entity type 'node' references a target entity type 'taxonomy_term', which does not exist.
```
## Fixing setup issues
The test is trying to install the `field_tags`, but it's missing a dependency. Tags reference a taxonomy term, but we haven't enabled the Taxonomy module within the test.
Enable the `taxonomy` module by adding it to the `$modules` array, and the error should change:
> Exception when installing config for module atdc_test, message was: Missing bundle entity, entity type node_type, entity id post.
As well as the field configuration, we also need to create the Post content type.
This can be done by creating a `node.type.post.yml` file:
If `$this->tags` is not empty, create a new taxonomy term for each one and save it to the post.
## Adding tag assertions
As well as asserting we have the correct number of tags, let's also assert that the correct tag names are returned and that they are the correct type of term.
To assert the tags array only includes taxonomy terms, use `self::assertContainsOnlyInstancesOf()`, and to check each term has the correct term type, loop over each term and use `self::assertSame()`.
Next, add some new assertions to the test to check the tag names match the specified tags.
These should pass as we already have code for them, but to see them fail, try changing a term type or tag name in the assertion or when creating the post to ensure the test works as expected.
## Conclusion
In this lesson, you learned how to add the configuration required for tests by creating a custom test module with the required configuration and how to install it within the test so configuration, such as fields, are available.
You created `PostBuilderTest` - a Kernel test for testing `PostBuilder`.
In the next lesson, we'll look at unit testing and start to wrap up this course.