uuid: - value: a1d0e52d-4cfc-4695-97f8-7f8a4c1a2938 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:32+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: | Which type of test should I use? created: - value: '2023-09-13T00:00:00+00:00' changed: - value: '2025-05-11T09:00:32+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2023/09/13/which-type-of-test-should-i-use langcode: en body: - value: |
Drupal offers a few different types of tests you can use, but how do you know which one to pick?
This is how I decide based on what I need to test by asking these questions:
Do I need to make GET or POST requests to a URL and check its response code, e.g. to check the endpoint exists, that I get an expected "Page not found" or "Forbidden" message, or to check if an item was created or updated?
If so, use a Functional
test like BrowserTestBase
.
BrowserTestBase
doesn't include JavaScript, so use a FunctionaJavaScript
test if needed.
If I don't need to make HTTP requests but need access to the service container, I use a Kernel test such as KernelTestBase
.
There's more setup for kernel tests compared to functional tests, such as installing the required configuration and creating schema tables in the database. However, having less installed means the tests run faster.
There are different base classes, such as EntityKernelTestBase
, that can be used depending on the situation to simplify the setup.
If I can test the code without needing the service container and mock simple dependencies, then use a Unit
test.
These are very fast to run, but you can overuse mocks and sometimes test the mocks instead of the code you intended to test.
As well as the regular unit test type, Drupal offers various types of test that can be used depending on the situation.
I like to start with functional tests first and switch to kernel or unit tests when needed. They're slower to run but easier to write as they need less setup and arguably provide the most value.
If you're just getting started with testing, they're probably the quickest to learn too.
format: full_html processed: |Drupal offers a few different types of tests you can use, but how do you know which one to pick?
This is how I decide based on what I need to test by asking these questions:
Do I need to make GET or POST requests to a URL and check its response code, e.g. to check the endpoint exists, that I get an expected "Page not found" or "Forbidden" message, or to check if an item was created or updated?
If so, use a Functional
test like BrowserTestBase
.
BrowserTestBase
doesn't include JavaScript, so use a FunctionaJavaScript
test if needed.
If I don't need to make HTTP requests but need access to the service container, I use a Kernel test such as KernelTestBase
.
There's more setup for kernel tests compared to functional tests, such as installing the required configuration and creating schema tables in the database. However, having less installed means the tests run faster.
There are different base classes, such as EntityKernelTestBase
, that can be used depending on the situation to simplify the setup.
If I can test the code without needing the service container and mock simple dependencies, then use a Unit
test.
These are very fast to run, but you can overuse mocks and sometimes test the mocks instead of the code you intended to test.
As well as the regular unit test type, Drupal offers various types of test that can be used depending on the situation.
I like to start with functional tests first and switch to kernel or unit tests when needed. They're slower to run but easier to write as they need less setup and arguably provide the most value.
If you're just getting started with testing, they're probably the quickest to learn too.
summary: null field_daily_email_cta: { }