はじめに phpunitを使ってユニットテストを書こうとしたところつまづいてしまったので備忘録としてまとめてみました。 誤りがございましたら、コメントいただけるとありがたいです。 laravel6.20.37 phpunit8.0 機能の把握 質問サイトでの投稿機能です。 QuestionController <?php namespace App\Http\Controllers; use App\Http\Requests\QuestionRequest as QuestionRequest; use App\Question; class QuestionController extends Controller { public function store(QuestionRequest $request, Question $question) { $question->fill($request->all()); $question->user_id = $request->user()->id; $question->save(); return redirect(route('home')); } } テスト QuestionControllerTest.php <?php namespace Tests\Feature; use App\Question; use App\User; use Illuminate\Foundation\Testing\RefreshDatabase; use Tests\TestCase; class QuestionControllerTest extends TestCase { use RefreshDatabase; public function testQuestionStore() { $user = factory(User::class)->create(); $question = factory(Question::class)->create(); $response = $this->withoutMiddleware()->actingAs($user) ->post(route('questions.store'), ['question' => $question]); $response->assertRedirect(route('home')); $this->assertDatabaseHas('questions', [ 'id' => $question->id, ]); } } RefleshDatabase use RefreshDatabase; RefreshDatabaseトレイトを使用し、データベースをリセットしています。 また、テスト中のトランザクション処理をテスト終了後になかったことにしています。 factory関数 $question = factory(User::class)->create(); $question = factory(Question::class)->create(); factory関数を使用することでテストに必要なモデルのインスタンスを生成できます。 ここでは、UserモデルとQuestionモデルをDBに保存しています。 また、factory関数を利用するにはモデルのファクトリを用意する必要があります。 UserFactory.php use App\User; use Faker\Generator as Faker; use Illuminate\Support\Str; $factory->define(User::class, function (Faker $faker) { return [ 'name' => $faker->name, 'email' => $faker->unique()->safeEmail, 'email_verified_at' => now(), 'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password 'remember_token' => Str::random(10), ]; }); QuestionFactory.php use App\Question; use Faker\Generator as Faker; use App\User; $factory->define(Question::class, function (Faker $faker) { return [ 'title' => $faker->text(50), 'body' => $faker->text(255), 'solution' => $faker->boolean(), 'user_id' => function () { return factory(User::class); }, ]; }); post送信 $response = $this->withoutMiddleware()->actingAs($user) ->post(route('questions.store'), ['question' => $question]); postを送信するテストでは、ミドルウェアを無効にする必要がある場合があるため、withoutMiddleware()を使い、一時的にミドルウェアを無効にしています。 actingAs($user)では生成したUserモデルでログインした状態を作り出しています。 postの第一引数ではuri、第二引数で'question'をkeyにしたQuestionモデルを渡しています。 assertRedirect $response->assertRedirect(route('home')); 次にassertRedirectメソッドでpost送信された後にリダイレクトされているかをチェックしています。 DBテスト $this->assertDatabaseHas('questions', [ 'id' => $question->id, ]); 最後にassertDatabaseHasメソッドでデータベーステーブルに対して条件に合ったレコードが存在するのかをテストしています。 questionsテーブルに対し、先程作成したQuestionモデルのidが存在するかをテストしています。 Questionモデルはこのような形で$questionに格納されています。 {"id":1,"title":"Omnis id vel explicabo laboriosam voluptatum.","body":"Est ut saepe quam asperiores placeat est accusantium. Est sapiente sapiente tenetur eum soluta est aut. Dolores dolores quia autem quia ad id. Qui molestias quibusdam est corrupti qui necessitatibus.","solution":true,"user_id":3,"updated_at":"2021-11-23 13:01:14","created_at":"2021-11-23 13:01:14"} そのため、$question->idとすることでpostによってDBに保存されたレコードとファクトリーで作成されたモデルのレコードが同じであることをテストしています。 最後に factryを利用してpost送信するテストがあまりなかったため、記事にしてみました。 テストは大事ですのでどんどん書いていきたいと思います。

はじめに phpunitを使ってユニットテストを書こうとしたところつまづいてしまったので備忘録としてまとめてみました。 誤りがございましたら、コメントいただけるとありがたいです。 laravel6.20.37 phpunit8.0 機能の把握 質問サイトでの投稿機能です。 QuestionController <?php namespace App\Http\Controllers; use App\Http\Requests\QuestionRequest as QuestionRequest; use App\Question; class QuestionController extends Controller { public function testQuestionStore() { $user = factory(User::class)->create(); $question = factory(Question::class)->create(); $response = $this->withoutMiddleware()->actingAs($user) ->post(route('questions.store'), ['question' => $question]); $response->assertRedirect(route('home')); $this->assertDatabaseHas('questions', [ 'id' => $question->id, ]); } } テスト QuestionControllerTest.php <?php namespace Tests\Feature; use App\Question; use App\User; use Illuminate\Foundation\Testing\RefreshDatabase; use Tests\TestCase; class QuestionControllerTest extends TestCase { use RefreshDatabase; public function testQuestionStore() { $user = factory(User::class)->create(); $question = factory(Question::class)->create(); $response = $this->withoutMiddleware()->actingAs($user) ->post(route('questions.store'), ['question' => $question]); $response->assertRedirect(route('home')); $this->assertDatabaseHas('questions', [ 'id' => $question->id, ]); } } RefleshDatabase use RefreshDatabase; RefreshDatabaseトレイトを使用し、データベースをリセットしています。 また、テスト中のトランザクション処理をテスト終了後になかったことにしています。 factory関数 $question = factory(User::class)->create(); $question = factory(Question::class)->create(); factory関数を使用することでテストに必要なモデルのインスタンスを生成できます。 ここでは、UserモデルとQuestionモデルをDBに保存しています。 また、factory関数を利用するにはモデルのファクトリを用意する必要があります。 UserFactory.php use App\User; use Faker\Generator as Faker; use Illuminate\Support\Str; $factory->define(User::class, function (Faker $faker) { return [ 'name' => $faker->name, 'email' => $faker->unique()->safeEmail, 'email_verified_at' => now(), 'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password 'remember_token' => Str::random(10), ]; }); QuestionFactory.php use App\Question; use Faker\Generator as Faker; use App\User; $factory->define(Question::class, function (Faker $faker) { return [ 'title' => $faker->text(50), 'body' => $faker->text(255), 'solution' => $faker->boolean(), 'user_id' => function () { return factory(User::class); }, ]; }); post送信 $response = $this->withoutMiddleware()->actingAs($user) ->post(route('questions.store'), ['question' => $question]); postを送信するテストでは、ミドルウェアを無効にする必要がある場合があるため、withoutMiddleware()を使い、一時的にミドルウェアを無効にしています。 actingAs($user)では生成したUserモデルでログインした状態を作り出しています。 postの第一引数ではuri、第二引数で'question'をkeyにしたQuestionモデルを渡しています。 assertRedirect $response->assertRedirect(route('home')); 次にassertRedirectメソッドでpost送信された後にリダイレクトされているかをチェックしています。 DBテスト $this->assertDatabaseHas('questions', [ 'id' => $question->id, ]); 最後にassertDatabaseHasメソッドでデータベーステーブルに対して条件に合ったレコードが存在するのかをテストしています。 questionsテーブルに対し、先程作成したQuestionモデルのidが存在するかをテストしています。 Questionモデルはこのような形で$questionに格納されています。 {"id":1,"title":"Omnis id vel explicabo laboriosam voluptatum.","body":"Est ut saepe quam asperiores placeat est accusantium. Est sapiente sapiente tenetur eum soluta est aut. Dolores dolores quia autem quia ad id. Qui molestias quibusdam est corrupti qui necessitatibus.","solution":true,"user_id":3,"updated_at":"2021-11-23 13:01:14","created_at":"2021-11-23 13:01:14"} そのため、$question->idとすることでpostによってDBに保存されたレコードとファクトリーで作成されたモデルのレコードが同じであることをテストしています。 最後に factryを利用してpost送信するテストがあまりなかったため、記事にしてみました。 テストは大事ですのでどんどん書いていきたいと思います。

はじめに 自分はよく、「WSL2 + Docker + Laravel + React(or Vue)」環境で開発していて、動作が遅すぎて毎度イライラし、作業効率を大幅に下げていました。 シンプルにメモリのせいだと思い、メモリを増築・・・ しかし、それでも大差のない遅さ。 なんでだろうと思って色々調べたときに、対策したメモです。（Windows環境です。） Mac環境であれば、@ucan-labさんの https://qiita.com/ucan-lab/items/a88e2e5c2a79f2426163 をご参照ください。大変わかりやすいです。いつも大変お世話になっております・・・ ちなみに、ReactやVueとかの環境を作っている場合にもかなり効果的でした。 （npm run devとかするときですね。） 結論 「\\wsl$\Ubuntu-20.04\mnt\」配下に、プロジェクトを配置するのではなく、 「\\wsl$\Ubuntu-20.04\home\」配下に、プロジェクトを配置。 ※Ubuntuのバージョンは、良しなに・・・ つまり、 「¥¥wsl$\Ubuntu-20.04¥home¥」配下に、 Dockerfileとかdocker-componse.ymlがある場所で 「docker-compose up -d --build」とかをしてみる。 ということです。 内容 動作が遅くなっている理由として、 WindowsとLinuxのOSファイルシステム間でのファイル読み込みが遅くなっていることが原因です。 WSLがどういう構造で、どういうフォーマット形式で動作しているのかなどの確認をしたい場合には、 参考のリンクを参照ください。めちゃくちゃわかりやすいです、どちらも。 所感 ほんと、とんでもなく速くなっているので、なんでもっと早く気付かなかったのだろうと・・・ とにかく、「WSL2 + Docker + Laravel + React(or Vue)」などの環境で動作が遅いことを気にされている方は一読を。 参考 https://www.aska-ltd.jp/jp/blog/197 https://snyt45.com/posts/20210806/wsl2-multiple-linux-distribution/

ここでは一般的なクラスやabstract、trait、interfaceなどの使い方をまとめたいと思います。 classの使い方 クラスは変数・定数やメソッドを一つにまとめたもの。 役割ごとにクラスを作り、そのインスタンスを使ってプログラムを動かすことをオブジェクト指向という。 class_example.php class Product{ //公開条件にはpublic、protected、privateがある。 // publicは外から使える→インスタンス後にアクセスできるということ // protectedは自分と継承先のクラスが使うことができる // privateはクラス内でしかプロパティやメソッドにアクセスできない→変数などはprivateが安全(外から書き換えられないから) // 変数 private $product = []; // 関数 // コンストラクトメソッドはクラスがインスタンス化される際に呼び出される // $thisはnewによりインスタンス化したオブジェクトを指す function __construct($product=null){ $this->product[] = $product; } public function getProduct(){ $products = $this->product; foreach($products as $product){ echo $product; } } public function addProduct($item){ $this->product[] = $item; } // staticはクラスメソッドを定義できる // Class::メソッド名()で使うことができる public static function getStaticProduct($str){ echo $str; } } $instance = new Product('インプット'); $instance->getProduct(); => 'インプット' $instance->addProduct('追加'); $instance->getProduct(); => 'インプット' => '追加' Product::getStaticProduct('静的'); => '静的' 継承 クラスは単一継承の機能を持ち、一つのクラスを継承できる。 親クラスの変数やメソッドなどを子クラスが使えるようになる。 class Parente{ protected $parentVariable = '親の変数です'; public function parentfunc(){ echo "親の関数です"; } } class Child extends Parente{ public function test(){ echo $this->parentVariable; } } $instance = new Child(); $instance->test(); => '親の変数です' // 変数のアクセス修飾子はprotectedなので継承先のクラス内でも使える $instance->parentfunc(); => '親の関数です' インターフェイス 継承先のクラスにメソッドの強要を行う。 インターフェイス内に書かれているメソッドは継承先のクラスで用いなければならない。 インターフェイスは中身のないpublicメソッドしか書けない、インスタンス化はできない。 継承方法はimplementsを使い、何個でも継承できる。 interface ExampleInterface{ // helloメソッドを継承先のクラスに置いて定義しなければエラーが出る public function hello(); } interface ExampleInterface2{ // goodMorningメソッドを継承先のクラスに強制 public function goodMorning(); } class Example implements ExampleInterface, ExampleInterface2{ public function hello(){ echo 'こんにちは'; } public function goodMorning(){ echo 'おはよう'; } } どんな時に使うのか謎ですが、何かソースコードをみながら理解を深めたいと思います。 抽象クラス 抽象クラスはクラスにインターフェイスの機能を持たせたようなクラス。(インスタンス化はできない) abstract class クラス名Abstractと定義する。 わかりやすいようにクラス名にAbstractとつける場合が多い。 メソッドの強制とメソッドを提供する。 メソッド定義の前にabstract public(protected) 〜とつけるとそのメソッドを継承先のクラスで強制する。 <?php abstract class ExampleAbstract{ protected $abstractVariable = '抽象クラスの変数です'; public function goodEvening(){ echo 'こんばんは'; } abstract protected function hello(); } class Example extends ExampleAbstract{ public function hello(){ echo 'こんにちは'; echo $this->abstractVariable; } public function goodMorning(){ echo 'おはよう'; } } $instance = new Example(); $instance->hello(); => 'こんにちは抽象クラスの変数です'; $instance->goodEvening(); => 'こんばんは'; トレイト クラスは単一継承のため、一つのクラスしか継承できませんが、トレイト何個でも継承することができるクラスのようなもの(インスタンス化はできない) trait トレイト名で使用する。 使うときは使いたいクラス内でuseする。 trait ExampleTrait{ protected $traitVariable = '抽象クラスの変数です'; private $traitPrivateVariable = 'トレイトのプライベート変数です'; public function hello(){ echo 'こんにちは'; } } trait ExampleTrait2{ public function goodEvening(){ echo 'こんばんは'; } } class Example{ use ExampleTrait; use ExampleTrait2; public function goodMorning(){ echo 'おはよう'; echo $this->traitVariable; echo $this->traitPrivateVariable; } } $instance = new Example(); $instance->goodMorning(); =>'おはよう抽象クラスの変数ですトレイトのプライベート変数です' trait内で定義したprivate変数もuse先のクラスで普通に使えました。。。 traitはとても使いやすそうな感じがしました。クラスを拡張してくれる感じで。 おわりに メソッドの強制などはどうやって使うのか謎が深まりましたが、とりあえずphpにおけるクラスの使い方をアウトプットしました。またクラス関係で学習したものはここに追記していく予定です。

＜エラー概要＞ ◉LaravelMix学習 表題の通り、上記コマンドでエラー発生 SyntaxError: Identifier 'mix' has already been declared ＜仮説＞ ◉コードを書き換える際に余分なコードを記載してしまった。 ◉エラー文よりすでに定義された変数や定数が再定義されている ＜解決方法＞ webpack.mix.js const mix = require('laravel-mix'); こちらのコードがなぜか二行書いてしまっており一行削除し解決に至りました。 エラー文の通り、 すでに定義mixという変数が再定義されているということでした。 ＜感想＞ 今回のエラーはエラー分をじっくり読めば解決できるものでした。 引き続き頑張ります！ 補足アドバイスがあれば是非お願いいたします。

背景 Laravelプロジェクトアサイン当初、VSCodeの拡張機能PHP Intelephenseにより、知らないメソッドはよくジャンプしてvender/laravel配下を読みに行くことが多かった そんな中、以下コードを見た $query->whereLike('code', $this->input) このwhereLikeというメソッドを見て 「LaravelはLIKE検索もできるwhere句もあるんだ～」 とのんきにPHP Intelephenseでジャンプしようと思ったらできない。 おや？ ジャンプできない理由は謎だったが、ドキュメントを確認すると、whereLikeなんてメソッドはない… よくよく調べるとプロジェクト内にこんなソースコードを発見 Builder::macro('whereLike',function... 「なんじゃこりゃ…？」 macroというワードとそれ以降に書いてある（特に第2引数）コードの意味がよく分からんかったので、深く理解しようというのが今回の背景 目的 macroを理解する ※きっかけとなったwhereLikeをわざわざ作った背景等はもう一つ上の次元なので、一旦割愛 気になる方は概要理解 https://qiita.com/take_3/items/1154ecbd8033a9a3beaf 環境 Laravel 8.x 内容 前提 今回はmacroを知ったきっかけであるBuilderで理解進める Collectionにもmacroがあるらしい。 こっちも利用頻度高いと思うので、取り上げる 概要 まずは1次情報からということで公式ドキュメントで 8.x macro で検索すると、8件のヒット（21/11現在） そもそも「マクロとは？」の答えは以下 関連する複数の操作や手順、命令などを一つにまとめ、必要に応じて呼び出すことができるようにする機能 ※参考↓ https://e-words.jp/w/マクロ.html なるほど、意味を知ってしまえばそんな難しくない 「一つにまとめて、必要に応じて使う」といいう点からサービスコンテナの延長の概念だなと感じた 使い方－Builder 公式ドキュメントに沿って行く ソースコード マクロの登録 ExampleServiceProbiver.php use Illuminate\\Support\\Facades\\Response; use Illuminate\\Support\\ServiceProvider; use Laravel\\Scout\\Builder; /** * 全アプリケーションサービスの初期起動処理 * * @return void */ public function boot() { Builder::macro('count', function () { return $this->engine->getTotalCount( $this->engine()->search($this) ); }); } 記述するのは場所はどこでもいいと思うが、一般的には公式と同じようにサービスプロバイダ―に記述することが多そう（推測） そうすれば、いつでも使いたい時に作ったメソッドを使用できるから Builderの場合はLaravel\\Scout\\Builder内にあるmacroメソッドを使う。引数は 第2引数：メソッド名 第3引数：メソッドによる処理内容 マクロの使用 ExampleController.php use App\\Models\\Order; Order::search('Star Trek')->count(); あとはどこでも使うだけ。 すごく楽。 使い方－Collection こちらも公式ドキュメントに沿って行く ソースコード マクロの登録 ExampleServiceProbiver.php use Illuminate\\Support\\Collection; use Illuminate\\Support\\Str; Collection::macro('toUpper', function () { return $this->map(function ($value) { return Str::upper($value); }); }); 95%くらいbuilderと同じ Biulderと異なるのはmacroメソッド本体の設定場所くらい 記述するのは場所はどこでもよさそう。（理由は上述の通り） Collectionの場合はIlluminate\\Support\\Collection内にあるmacroメソッドを使う。引数はBuilderと同じ以下の通り 第2引数：メソッド名 第3引数：メソッドによる処理内容 今回はtoUpperというメソッドをCollectionに対して使うことで、Collection内の文字列を大文字にするマクロを作った模様。 マクロの使用 使用もBuilderと同じ。 ExampleController.php $collection = collect(['first', 'second']); $upper = $collection->toUpper(); dump($upper) // ↓出力結果 // ['FIRST', 'SECOND'] 無事、小文字→大文字に変換されております。 補足 他にはレスポンスに対してマクロを登録したり、 そのレスポンスをサービスプロバイダで依存注入（DI）してマクロ登録したり 結構いろんなところで使える。 Laravelのみならず、macroと類似した機能は他の言語にも存在する C言語ではdefineという関数らしい https://www.sejuku.net/blog/25927 所見 ただの感想 サービスプロバイダに記述するあたりなどみて 独自の処理をメソッドにギュッと凝縮していつでも使える感じにした「お手軽サービスコンテナ」だな という直感的な感想です笑 そもそも現状でもかゆいところに手が届くくらい、組み込み関数は充実している感があるが、 「使いたいやつないなら、自分で作って」 と言わんばかりにサービス精神あふれるLaravelはしゅごい。 引っかかる点 ただ、Builderについてはスコープ、Collectionについてはアクセサがある 個人的主観としては、以下の使い分けのイメージ 汎用度が相対的に高い（＝スコープが相対的に広い）：マクロ 扱うリソースが多岐にわたる（User, Order, Post…etc） 汎用度が相対的に低い（＝スコープが相対的に狭い）：スコープ、アクセサ 扱うリソースが限られている（User内だけとか） ただ、そうなると、 マクロとサービスコンテナとの使い分けは？ とかの疑問がわくので、ここら辺は実務で使っていく中で言語化していこうと思います。

＜エラー概要＞ ◉Laravel学習 http://localhost:8000/admin/profile/create に接続を試みるも、 404 Not found と出力されうまく実行できない。 ＜仮説／試したこと＞ ◉ルーティングの記述確認 php artisan route:list ＜原因／結果＞ admin/news/create admin/news/delete admin/news/edit →このようにprofileのルーティングが全くできていませんでした、、 route/web.php Route::group(['prefix' => 'admin'], function() { //ProfileController Route::get('profile/create', 'Admin\ProfileController@add'); Route::get('profile/edit', 'Admin\ProfileController@edit'); Route::post('profile/create', 'Admin\ProfileController@create'); Route::get('profile/index', 'Admin\ProfileController@index'); }); 上記のように追記し解決に至りました。 ＜感想＞ 　「ルーティングはしっかり出来ているはず！」という謎の思い込みから解決に時間を要してしまいました。 自分を疑い続けることは大切だと再認識できました。 今週は学習が中だるみしてしまったので11月最後まで走りきります！

xdebug php.iniの設定例。 ; 以下の設定だと、IntelliJのRUNではxdebug.modeの設定が無しで実行されるのでmode=developとして実行され、 ; DEBUGではIntelliJ側でxdebug.mode=debugが設定されて実行されるのでブレークポイントが働くようになります xdebug.mode=develop xdebug.start_with_request=yes xdebug.client_host=host.docker.internal xdebug.client_port=9003 xdebug.log=/var/log/php/xdebug.log 上記はPHP8 xdebug3の設定です。 ※PHP7xdebug2だと設定キーと値が異なります Dockerの設定追加 Virtual machine pathとLocal Pathの対応が一致するように、Path mappingsも設定しましょう。例えばDockerの/var/www/abc.phpが、ホストの/Users/xxx/src/abc.phpと一致させるような設定です。 PHP CLI Interpreterの設定追加 PHP Remote Interpreterのプラグインが必要です。「...」をクリック。 Serverは先ほど追加したDockerを指定。今回はDocker Composeを使っているので、Configuration filesでdocker-compose.ymlを指定。ServiceにはPHPが動作するサービスを指定します。 Runを実行してみる 試しにLaravelのartisanを実行。 artisanの標準出力を確認できればRemote Interpreterの設定は問題ないです。DockerのPHPで実行できてます。 ブレークポイントを設定して、Debugを実行しても止まらない Start Listening for PHP Debug ConnectionsでListening状態にします。緑色になっていればOK。 artisanの最初の行でブレークポイントを設定して、Debugを実行してみます。 しかし、ブレークポイントで停止せず、以下のエラーが表示されました。 Connection was not established. Probably 'xdebug.remote_host=host.docker.internal' is incorrect. Change 'xdebug.remote_host' IntelliJ IDEA側の実行ログを見ても-dxdebug.client_host=host.docker.internalがあるのですが、incorrectと表示されます。 エラーを回避するため、設定を加えます。 デバッグ実行できるよう設定を追加 php実行側の接続先の名称と、IntelliJ IDEA / PhpStormの名称を揃えて、一致させるような設定です。 名称を「laravelproject-php-xdebug-server」とします。 環境変数PHP_IDE_CONFIGの設定 docker composerの設定例です。 version: "3" services: laravelproject-php-xdebug: environment: PHP_IDE_CONFIG: "serverName=laravelproject-php-xdebug-server" IntelliJ IDEA / PhpStormのPHP Serversの設定 Serversに「laravelproject-php-xdebug-server」を追加。path mappingsも設定します。 PHP CLI InterpreterにConfiguration Optionsを追加 以下設定を加えておかないと接続が不安定なので追加します。 -dxdebug.client_port=9003 -dxdebug.client_host=host.docker.internal DEBUG実行時に、xdebug.client_portは9000で勝手にセットされるみたいで9003を別途設定しています。xdebug.client_hostもhost.docker.internalで自動セットされるので不要っぽく見えるのですが、なぜか無いと接続できない時があってその原因がわかってないので、とりあえず追加しています。 改めて、ブレークポイントを設定して、Debugを実行 無事、停止されました。 dockerのbashからデバッグ実行する dockerのシェルからデバッグを開始したい場合。 # -dxdebug.mode=debugを追加してphpを実行 $ PHP_IDE_CONFIG=serverName=laravelproject-php-xdebug-server php -dxdebug.mode=debug artisan php.iniでxdebug.mode=developにしているため、debugを指定しました。 IntelliJ IDEA / PhpStormからPHPUnitをデバッグ実行する Test Frameworksを追加します。Test RunnerのDefault configuration fileは、virtual側のパスでphpunit.xmlを指定します。 PHPUnitのTestファイル開いて、「>>」の「Debug〜」からDEBUGを実行します。 ブレークポイントも動作しています。