Pestとは

PHPのTesting Frameworkの一種
一番有名なのは、PHPUnitで、２番目にPestらしい
Pestは、シンプルさを追求している。
JavaScript Testing FrameworkのJestと名前が酷似しているが、書き方も非常に似ている
Jest慣れている人は、PHPUnitより断然Pestの方が書きやすいと思う

https://pestphp.com/

wadakatu 2023/03/22

Pest V2

2023/3/20にPestのバージョン２がリリースされた。
PestのWebサイトデザインも丸々変更するほどの気合の入りっぷり。
PestV2の開発には、約18ヶ月の歳月をかけて、500コミット以上しているとのこと。

wadakatu 2023/03/22に更新

主要な変更点

1. Architecture Testing

全体のコードの品質維持

https://pestphp.com/docs/arch-testing

2. Optimizing Tests / Parallel Testing

並列テスト時の実行速度向上

3. Optimizing Tests / Profiling

テスト実行結果の可視化

4. Optimizing Tests / Compact Printer

テスト実行後、失敗したテストのみ表示

5. Test Filtering / --retry

前回失敗したテストのみ実行

6. Test Filtering / --dirty

変更があったファイルのみテストを実行

7. Test Filtering / --bail

テストに失敗した時点で、テスト実行を停止

8. Skipping Tests / Creating Todos

テストスーツの中でTodo管理可能

9. Custom Expectations / Intercept Expectations

各expectaions関数の動作を上書きすることが可能

10. Datasets / Scoped Datasets

特定の機能やとあるファイル内でのみ使用するDatasetを定義可能

各変更点の詳細は、明日以降記載していく。

wadakatu 2023/03/23に更新

1. Architecture Testing

全体のコードの品質維持

アプケーションは、時間が経てばコードはレガシーになっていき、開発する人も変わっていくものなので全体のコードの品質維持がとても難しくなる。
そういった悩みを解決するのが、Architecutre Testingである。
これを使って、アーキテクチャルールを明確にして、テストを記述しておけば、プルリクエストでレビューする前に何が間違っているかを見つけることができる。
無駄なレビュー工数の削減により、より速いデプロイが可能になり、チームの生産性向上にもつながる。

https://pestphp.com/docs/arch-testing

できること

toOnlyUse()

あるクラス内で、特定の名前空間を持つクラスや関数のみ呼び出されているかをテスト
- モデルクラス内では「Illuminate\Database」の名前空間を持つクラスが呼び出されているかどうかをテスト
```
test('models')
   ->expect('App\Models')
   ->toOnlyUse('Illuminate\Database');
```

toOnlyBeUsedIn()

特定のクラスが、アプリケーションの特定の一部でしか使用されないことをテスト
- モデルクラスが、リポジトリクラスでのみ使用されていることをテスト
```
test('models')
  ->expect('App\Models')
  ->toOnlyBeUsedIn('App\Repositories');
```

toBeUsed()

あるクラスや関数がアプリケーション全体で呼び出されていないかをテスト
- dd() dump()などが残っていないことをテスト
```
test('globals')
  ->expect(['dd', 'dump'])
  ->not->toBeUsed();
```

toBeUsedIn()

あるクラス内で、特定の関数やクラスが使用されていないことをテスト
- ドメインクラス内で「Illuminate\Http」の名前空間を持つクラスが使用されていないことをテスト
```
test('globals')
  ->expect('Illuminate\Http')
  ->not->toBeUsedIn('App\Domain');
```

toUse()

特定の関数やクラスが、あるクラス内で使用されていないことをテスト
- 「request」関数が、ドメインクラス内で使用されていないことをテスト
```
test('globals')
  ->expect('App\Domain')
  ->not->toUse('Illuminate\Http');
```

toUseNothing()

特定の名前空間やクラス内で、依存関係が１つもないことをテスト
- 「App\ValueObject」の名前空間を持つクラス内で、依存関係がないことをテスト
```
test('value objects')
  ->expect('App\ValueObjects')
  ->toUseNothing();
```

ignoring()

既出のメソッドと組み合わせて使用することで、特定の名前空間やクラスを例外扱いにできる
- 「Illuminate\Support\Facade」の利用を制限したいが、プロバイダークラスは例外として利用を許可する

 test('facades')
   ->expect('Illuminate\Support\Facades')
   ->not->toBeUsed()
   ->ignoring('App\Providers');

wadakatu 2023/03/27に更新

2. Optimizing Tests / Parallel Testing

並列テスト時の実行速度向上

Pestはデフォルトだと、単一のプロセス内でテストを実行する。
しかし、オプション --parallelを付与することで、マルチプロセスで並列テストを実行することが可能
その並列テストの実行速度をV1と比較すると、Pest V2では60%ほど向上している。
V1からV2にかけて、並行テストのコアシステムをリビルドしたおかげでこれほどまでの速度向上が得られたとのこと。

並列テスト実行

./vendor/bin/pest --parallel

並列テスト実行（プロセス数指定）

./vendor/bin/pest --parallel --processes=10

wadakatu 2023/03/27に更新

3. Optimizing Tests / Profiling

テスト実行結果の可視化

テストをたくさん書くと、テスト全体の実行速度がどんどん長くなります。
一般的には、テスト終了後は、全体の実行時間しか出力されずどのテストケースがボトルネックになっているかを見つけるのは手作業で１つずつテストを走らせて確認するという気が遠くなる作業が必要です。
しかし、--profileのオプションを付けることで、テスト実行後に実行時間が長いテストケースを一覧表示してくれるので、修正すべきテストケースが明確になります。

テスト実行（--profileあり）

./vendor/bin/pest --profile

wadakatu 2023/03/28

4. Optimizing Tests / Compact Printer

テスト実行後、失敗したテストのみ表示

テストを実行すると、通常は成功したテストと失敗したテストが全て表示されます。
しかし、大量のテストを書いていると、大事なのはどこでテストが失敗しているかです。
そこで、--compactのオプションを付けることで、失敗したテストのみテスト結果に出力します。
これにより、修正すべきテストが明確になり、生産性向上につながります。

テスト実行（--compactあり）

./vendor/bin/pest --compact

wadakatu 2023/03/28

5. Test Filtering / --retry

前回失敗したテストのみ実行

失敗したテストの修正を確認する際に、毎回全テストを動かすのは非効率です。
失敗したテストが１つや２つなら、テストクラスを指定して動かすのでも良いですが、失敗したテストが多くのテストクラスに跨っている場合、当てはまるテストクラスを全て指定するのは非常にめんどくさいです。
そんな時に、--retryのオプションを使うと、前回失敗したテストのみを抽出して再実行してくれます。

テスト実行（--retryあり）

./vendor/bin/pest --retry

wadakatu 2023/03/28に更新

6. Test Filtering / --dirty

変更があったファイルのみテストを実行

新機能の開発を行なっている場合、それ以前に書いたテストへは一切影響がないことがほとんどです。
そんな時に、--dirtyオプションを使うと、Gitの変更履歴を参照して、今回変更があったファイルと関連するテストのみ実行することが可能です。

テスト実行（--dirtyあり）

./vendor/bin/pest --dirty

wadakatu 2023/03/28

Test Filtering / --bail

テストに失敗した時点で、テスト実行を停止

通常だと、テストが失敗してもしなくても全てのテストが実行されます。
しかし、--bailオプションを利用することで、テストが１つ失敗した時点で、テスト実行が終了します。
失敗するテストケースがあまりに多いとやる気を無くしてしまいがちなので、このオプションを使って１つずつ失敗するテストケースを修正できるのは良さそう。

テスト実行（--bailあり）

./vendor/bin/pest --bail

wadakatu 2023/03/29に更新

8. Skipping Tests / Creating Todos

テストスーツの中でTodo管理可能

テストを書かないといけないが、書く時間がない時は、意外とよくあるものです。
しかし、人間は忘れる生き物なので、何か痕跡を残しておかないと、テストを書かないままずっと放置してしまうこともよくあります。
そこで、todo()を使用することで、テストを書くべきという痕跡を簡単に残すことができます。
そして、現在のtodo一覧が見たい時も、--todoオプションを利用することで簡単に確認することができます。

todo管理

it('database test')->todo();

test('page transition test')->todo();

todo一覧表示

./vendor/bin/pest --todo

wadakatu 2023/03/29に更新

9. Custom Expectations / Intercept Expectations

各expectaions関数の動作を上書きすることが可能

通常は、デフォルトで用意されているexpectations関数を用いれば、大抵のテストケースは問題なく実行可能です。
もし既存のexpectations関数の動作を上書きしたい場合は、intercept関数を使いましょう。

例：`toBe()`

本来、toBe関数は、expect()内に記載された値がtoBe()内の値と一致しているかのアサーションを実行します。

expect(1)->toBe(1);  // 1 = 1 であることをアサーション

このtoBe関数を、ModelクラスのIDが一致しているかどうかというアサーションに変更したい場合は、intercept関数を用いて以下のように書きます。

// tests/Pest.php or tests/Expectations.php
expect()->intercept('toBe', Model::class, function(Model $expected) {
    expect($this->value->id)->toBe($expected->id);
});

従来通りのtoBe関数であれば、以下のように書きます。

// tests/Feature/ExampleTest.php
test('models', function () {
    $userA = User::find(1);
    $userB = User::find(1);
 
    // IDを明示的に取得する必要がある。
    expect($userA->id)->toBe($userB->id); 
});

しかし、今回の場合intercept関数で、toBe関数内部でidを取り出すようにしているので、以下のような書き方で同じアサーションが可能です。

// tests/Feature/ExampleTest.php
test('models', function () {
    $userA = User::find(1);
    $userB = User::find(1);
 
　// モデルクラスを渡すだけ（idの値はtoBeの内部で検証される）
    expect($userA)->toBe($userB);
});

wadakatu 2023/03/29に更新

10. Datasets / Scoped Datasets

特定の機能やとあるファイル内でのみ使用するDatasetを定義可能

Pestでは、データセットをどこでも作成することが可能です。

dataset('products', [
    'egg',
    'milk'
]);

しかし、時には、データセットが特定の機能やフォルダーセットに依存する場合があります。
このような場合、Datasetsフォルダ全体にデータセットを配布するのではなく、必要なデータセットを要求する関連するフォルダ内にDatasets.phpファイルを生成し、データセットの範囲をそのフォルダに制限することができます。

先ほどのproductsのデータセットを例に挙げてみます。
tests/Feature/Products/Datasets.phpにproductsデータセットを作成した場合

// 使用可能
// tests/Feature/Products/ExampleTest.php...
it('has products', function (string $product) {
    expect($product)->not->toBeEmpty();
})->with('products');

// 使用不可
// tests/Feature/Users/ExampleTest.php...
it('has users', function (string $product) {
    expect($product)->not->toBeEmpty();
})->with('products');

このように、データセットが使用できる範囲を簡単に制限することができます。

前者のテストは、productsデータセットが置かれているディレクトリ内に書かれたテストなので、productsデータセットを利用することができます。
反対に、後者のテストはproductsデータセットが置かれているディレクトリ外で書かれたテストなので、productsデータセットを利用することができません。

このスクラップは2023/07/13にクローズされました

Pestとは

Pest V2

主要な変更点

1. Architecture Testing

2. Optimizing Tests / Parallel Testing

3. Optimizing Tests / Profiling

4. Optimizing Tests / Compact Printer

5. Test Filtering / --retry

6. Test Filtering / --dirty

7. Test Filtering / --bail

8. Skipping Tests / Creating Todos

9. Custom Expectations / Intercept Expectations

10. Datasets / Scoped Datasets

1. Architecture Testing

できること

toOnlyUse()

toOnlyBeUsedIn()

toBeUsed()

toBeUsedIn()

toUse()

toUseNothing()

ignoring()

2. Optimizing Tests / Parallel Testing

並列テスト実行

並列テスト実行（プロセス数指定）

3. Optimizing Tests / Profiling

テスト実行（--profileあり）

4. Optimizing Tests / Compact Printer

テスト実行（--compactあり）

5. Test Filtering / --retry

テスト実行（--retryあり）

6. Test Filtering / --dirty

テスト実行（--dirtyあり）

テスト実行（--bailあり）

8. Skipping Tests / Creating Todos

todo管理

todo一覧表示

9. Custom Expectations / Intercept Expectations

例：toBe()

10. Datasets / Scoped Datasets

例：`toBe()`