LaravelJPConference楽しみですね！
いやー楽しみだ。
……って私今回楽しみにしてるだけ側じゃなかった(； ･`д･´)
ってことで、準備をしよう。
ということで、やるべきことをリスト化してみよう。
1. スケジューリング 2. 目次作成 3. タイトルのみスライド作成 4. ソースコード集め 5. 関係者(02)に許可もらう 6. 絵の素材集め 7. プレゼンの練習日確保 8. 練習しながらブラッシュアップ
こんな感じかな？
このままスケジュールーって言っても、予定立てて満足して、後で慌てる夏休みの宿題になるので。
この2つはやりたい！これで何もしないまま本番直前に慌てることはないでしょう(‘ω‘ )
ってことで、次回はスケジューリングですね。
これからふぁいとーわたし！
こちらで軽く内容触れています。
overloadは、対象のクラスがインスタンス化されたとき、全てのインスタンスが入れ替わります。
では、以下のようなコードがあったとき、
function func() {
$user = $this->xxx_repository->xxx();
$some_obj = $this->yyy_repository->yyy();
$zzz_obj = $this->zzz_service->zzz();
}
このときに、User::classをoverloadした。これで$userはいい感じに出来たなー
ってなって、もしzzz_serviceでUser::classがインスタンス化されてたら？
全てのコードを自分で書いたならまだしも、そうでなければ、知らないところでインスタンス化されている可能性があります。
予期しない動作が起こる可能性がある。それが、影響範囲の広いコードを扱うということです。
あ、説明のために書いたので、zzz_serviceモックするだろというツッコミはおいておいてください(´；ω；｀)
不要なところにまで影響するとかを考えると、予期しない動作が起こる可能性があります。
ちなみに、本当に必要な場合もあるので、理由なく安易に使わないでってだけです！
テスト通ったぜー！って思っていたら、実は本来通るべきではなかったとかあるので、注意してコード書こうと思いました！(ちなみに、実際通ってなかったです
該当するクラスのインスタンスが作成されたときに、そのインスタンスをモックオブジェクトにすり替えるよ！
Mockery::mock('overload:' . User::class);
これなら、ユーザークラスのインスタンスが作られたら、モックオブジェクトのインスタンスに変わってるよ！
これを使う状態って、テストコードがおかしいって一回疑ってもいいのかな？って思っています。
$xxx = $this->xxx_repository->get();
このときは、xxx_repositoryをモックして、そのreturn値をモックオブジェクトにしたり、
xxx_repositoryのstubをいい感じに作ってやるとか。
$xxx = new User();
ほら、ここでインスタンス化してるからoverloadしかなくないか？
って話だとしたら、その関数でUserインスタンスをインスタンス化するコードでいいの？とか。
例えばインスタンスを生み出すところを、ラップ関数にしてやるとか。
Userがモデルインスタンスとかなら、そもそもリポジトリに書いてやるべきとか。
関数内でnewすべき場合もあるかもですが、一度疑ってみてもいいかも
テストする関数外に対して、そのテストコードは干渉してたりしないかなとか。
あと、その後のテストがoverloadに依存してしまってるとかすると、各関数単体でテスト出来ないとか。
依存するのが正しいのであればいいですが、ちょっと見直してみてもいいかも。
最近テストコードで質問出たので、そのときに回答したことメモ
間違ってたら、教えてくれると嬉しいです(‘ω‘ )
Stubじゃなきゃ困るときもある理由を書いてみた。
Stubをちゃんと書けば、 どこかで該当関数の仕様を変えたときに、ちゃんと影響テストできるよね。 例えば、戻り値がModelオブジェクトからmixになったとか。 このとき、同じインターフェースで作っていればStubも変更するはずなので、 Stubを通したテストなら(ある程度)検知ができるよね。 もし、全ての関数をStub使わずモックで置き換えしていたら・・・ 仕様の変更は、全てのモック置き換えで握りつぶされちゃうね
Stubの目的と、モックの目的ってなんだろうってのも考え直したいやーつ。
モックでの置き換えって、個人的には既にテスト済みとか、テスト範囲外とかを置き換えるとかのイメージ。あと、Laravelとかで標準で実装されてるものとか（これもテスト済みコードと言い換えれる）。
あと、テストコード書いてるときに、なんのためのテストコード、何をテストしたいのかをもう少し考えて書きたい。
とりあえず、テストコード書くときに、何を確かめようとしているんだっけ？ってのを立ち止まって考えてみたいと思いましたまる。
テストを書くとき、テスト先コードにreturn値がなかった。これじゃテスト書くの難しくないか。
でも、テストを書くために元の仕様を変えるのってなんかおかしくない？
テストが難しいってことは、その関数が何をしているのか呼び出し元がわからないってこと。
return値がないとか、ログがないとか、エクセプションが握りつぶされてるとかって、テストコード書けないと思うけど、
それは呼び出し元が何をしているのかが検知できない状態だし、そのコードがおかしな状況になっているの可能性が高いってことじゃないかな。
つまり、テストコードを書けないというのは、それだけその関数が異常なのでは？
これは、あくまで最近あった一例であり、私の考え方の一つです。
でも、テストコードが書けない、それって今どういう状態なんだろう？っていうのを分析してみると、元コードの問題が見つけやすくなると思います。
そもそもテストしなくてもいいのではないかって言うのもあるので、是非一度立ち止まって考えてみてください！
休みだったけど、ちょこちょこ新しいことできたね！
簡単な動画作成を覚えた！
_ide_helperについて調べたり、自分のプロジェクトにも導入したりしたよ。
動画まだ一個しか作ってないから、定期的に作れるアイディア考えたい。
VRでなにかしたいと思う反面、単純にもったいない精神だから、無理にVRしなくてもいいのでは？って考えてる
とりあえず、切り替えたい。といいつつ、週末お出かけ予定だから、体調崩さないのが一番大切。
体調崩さないのが一番大切ぅ。
元気に週末迎えれるように頑張るぞー！
ide-helperなるものが作られているので、それを使ってみましょう。
composerで一個追加して、コマンド一つで出来ますよ！
composer require barryvdh/laravel-ide-helper
これで、ide-helperを作るためのツールが用意できます。
config/app.php
Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class,
を追加しておきましょう。5.5以降は不要です。
php artisan ide-helper:generate
これで、 _ide_helper.phpが出来上がりました。
こいつが超有能。
VSCodeやphpstormを使って、Facadeとかのクラスをいつもどおりメソッドジャンプしてみてください。
すると、 _ide_helper.phpにたどり着きます。
_ide_helper.phpには、Facadeの実装などが書かれているので、Facadeのメソッド、これどこに書かれてるんだ・・・？ってのを探すの大変でしたが、これで問題なく出来ます！
元コード探すときに、頑張って追うのが大変だったのが、ここを見れば一発でわかります(´；ω；｀)凄く助かってます・・・！
困ったら公式のREADMEを読んでみてください。開発者用のコマンドとかも書いてますので親切ですよ！
おつかれさまでした。
