diff --git a/src/content/daily-email/2023-11-18.md b/src/content/daily-email/2023-11-18.md
new file mode 100644
index 00000000..8ae8a8c8
--- /dev/null
+++ b/src/content/daily-email/2023-11-18.md
@@ -0,0 +1,48 @@
+---
+title: >
+  Writing good test names
+pubDate: 2023-11-18
+permalink: >
+  archive/2023/11/18/writing-good-test-names
+tags:
+  - software-development
+  - test-driven-development
+  - automated-testing
+  - php
+  - phpunit
+---
+
+In PHPUnit, there are different ways to write test methods.
+
+The standard way is to use camel-case method names with a `test` prefix, for example:
+
+```php
+public function testTheProjectNameShouldBeAString(): void
+{
+    // ...
+}
+```
+
+Another popular way, particularly in some frameworks, is to use snake-case method names:
+
+```php
+/** @test */
+public function the_project_name_should_be_a_string(): void
+{
+    // ...
+}
+```
+
+This may be more readable but only works if the `@test` annotation is present.
+
+What if you need to add another annotation, such as `@dataProvider` to the test? Do you do multi-line docblocks everywhere, or mix and match single and multiple line docblocks depending on the test?
+
+## Here's the thing
+
+My preference switches between both ways of writing test methods.
+
+But, whichever way I write it, I write descriptive method names that explain what the test does - even if it means having a long method name.
+
+I avoid short and generic names like `testUpdate()`.
+
+People should be able to read the test name and understand what it does and what it's testing.