oliverdavies.uk/source/_daily_emails/2023-11-18.md

title	pubDate	permalink	tags
Writing good test names	2023-11-18	daily/2023/11/18/writing-good-test-names	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:

public function testTheProjectNameShouldBeAString(): void
{
    // ...
}

Another popular way, particularly in some frameworks, is to use snake-case method names:

/** @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.