49 lines
1.3 KiB
Markdown
49 lines
1.3 KiB
Markdown
---
|
|
title: >
|
|
Writing good test names
|
|
pubDate: 2023-11-18
|
|
permalink: >-
|
|
daily/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:
|
|
|
|
```language-php
|
|
public function testTheProjectNameShouldBeAString(): void
|
|
{
|
|
// ...
|
|
}
|
|
```
|
|
|
|
Another popular way, particularly in some frameworks, is to use snake-case method names:
|
|
|
|
```language-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.
|