2022年4月17日日曜日

WordPressで単体テストをするには、シンボリックリンクを使う必要があるらしい。

WordPressで単体テストをしたい。

最近テストを書くのに開眼して、テストコードをとりあえず書きたくなりました。

WordPressのプラグインを作る上で、テストコードを導入したいと思い探していると、公式で以下の方法で試せばできると書いてありました。

  • wp-cliでテストコードの雛形を作成する
    wp scaffold plugin-tests "Plugin名"
    参考リンク
  • プラグインのディレクトリで./bin/install-wordpress-tests.shを実行する
  • phpunit をプラグインのディレクトリで実行する

いやー、かんたんに導入できるね。

現れるエラー

しかし、実行すると以下のエラーで悩まされる。

[17-Apr-2022 14:26:18 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /tmp/wordpress-tests-lib/includes/bootstrap.php:258) in /tmp/wordpress/wp-load.php on line 64

Warning: Cannot modify header information - headers already sent by (output started at /tmp/wordpress-tests-lib/includes/bootstrap.php:258) in /tmp/wordpress/wp-load.php on line 64

PHPUnitを実行しているはずなのに、ヘッダたないというエラーが出て手づまりになる。

StackExchangeに救いの手が

/tmpに作成されたwordpressのwp-config.phpをテスト用に作ったwp-config.phpに差し替えればうまく動いた。

ln -s /tmp/wordpress-tests-lib/wp-tests-config.php /tmp/wordpress/wp-config.php
PHPUnit via WP-CLI: Warning: Cannot modify header information ... bootstrap.php:68

2022年4月11日月曜日

PHPerKaigi2022に参加しました。

 PHPerKaigi2022に参加しました。
オンラインでの参加でしたが、面白かったですね。最近こういうイベント全然参加できてなかったけど、やっぱ久しぶりに参加すると楽しいですね。
今の会社にマジ感謝です。

PHPって自分が普段使っているもの(普段は5系と7系)以上に色々と可能性があって、面白い言語ですね。動的型付け言語なのに、やっぱり型がなくて辛くてそれが言語としてどんどんサポートしてくれてきてるのは嬉しい。8系少し書いてみたいな。

ありがたいことに普段なら絶対に関わりない人に質問拾ってもらったりして、めちゃくちゃ嬉しい一日でした。明日から業務がんばります。

0,1日目はこちら

ISUCON11のPHP実装は、何を考え、どのようにして作られていたのか 

Goで書かれたソフトをPHPに移植した話。静的型付け言語のGoに比べるとどうしてもパット見の情報量が少ないPHPでどうやって工夫したかという話で、非常に参考になった。
ISUCONは練習問題として非常に優秀とのことだったので、ちょっと解いてみようかなという機運が高まっている。(強い人がやるイメージだった。)

プロファイラの話。特にコードに手を入れなくてもプロファイルが使えるのは非常によい。かんたんに入れられそうなので入れてみたい。

今の会社に入って、テストデータをどうすればいいのだろうと迷っていたので、非常に勉強になった。
テストデータの準備には以下の3つのパターンがある。テストデータはインラインセットアップでまずは準備していき、共通化できそうなものを徐々に暗黙的セットアップに寄せていくという方針が自分の中で困っていた(暗黙的セットアップで完璧なテストデータを用意したほうがよいのではないかと思ってた)ので、非常に頭がスッキリした。
  • インラインセットアップ(テスト関数に書く方法)
  • 委譲セットアップ(関数で準備する方法)
  • 暗黙的セットアップ(テストフレームワークで予め用意されている方法で、毎テストごとに自動で呼ばれる)
残念ながらCakePHP Fixture Factoriesは使えないのだが…。

リモートワークでの困りごととそれの解決方法。朝会で困りごとは大体共有されない(顕在化しない)ので、困りごとを気軽に可視化できる仕組みを作っていたことが参考になった。

商品クラス、テーブルの誕生からでかすぎてどうしようもない状態になるまでの成長記録から、どのようにそれを避けていくかという話。
硬直化したソフトウェアは事業の成長を妨げる・止めるので、エンジニアとしてその状況は絶対に避けなければならない。
多角的にオブジェクトを見れる視野を持てる訓練をして、怪物を育てないことが大事。
怪物をどういうふうに手なづけていくかという話も聞きたかった。

HAHAHAHAHA

秘伝のタレ(継ぎ足せない・伝承したものしか作れない)をどうやって解消していくかという話。とりあえず新入りだけど、リファクタするかという勇気が組織を変えた話。


2022年4月10日日曜日

PHPerKaigi2022に参加してます

2022-04-09から開催されているPHPerKaigi2022にオンラインで参加しています。
オンラインで10時間セッション聞き続けるので、結構ヘロヘロなんですが学びがめちゃくちゃあります。

今日は参加したセッションについてメモをしておきます。

2022-04-09 前夜祭

Exceptionは握りつぶさずにロールバックしたり、ログに出力したりしてちゃんと処理しようという話。
これまで結構握りつぶしてきたので、開発で潰せるものは別にチェックしなくてもいいという話とキャッチしてもどうしようもないものは無視しても良いというのはなかった視点だった。

スプレッドシートで登録しているマスターデータのエラーをPHPで連携してNotionに記録しているよという話。
マスターデータの登録がスプレッドシートなので利便性はあるけど、すぐに壊れるから、それを検知できるというのはよいなと思った。

エラー監視ツールを入れて満足してませんか?っていう話。
エラー監視は入れたところがスタートで、まずはIssueの発生頻度を見える化し優先度の決定。
その後は、静的解析、テストコードを書くようにするのだが、これをカバレッジを意識しすぎると本質的ではないカバレッジ率を上げるテストばかり書いてしまう。まずはテストを書く習慣作りから始めると自然とテストが書かれていく。

Wordpressを改造するときはWordpressの作法にのっとろうという話。
独自実装すると思わぬところでつまづくが、その思わぬところが大体気づきにくいという恐ろしい話。

2022-04-10 1日目

予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント

コードを眺めて、自分の書いたコードのうちにエラーが発生しうる場所を特定する。
その問題が発生しそうなコードをどうやって問題発生しないようにするかの解説があった。
ちょっとまとめたいから後日書く。

Fibersの話。非同期処理の話だったが、Batch以外でPHPではあまり非同期処理を書く機会はなさそうかも。

既存のシステムを新規開発と移植を平行で行った話。コントローラ単位で移植してるって話やけど、Modelが結構破壊的な変更あったそうなんで、だいぶしんどそう。

1on1を公開する(もちろんできる範囲で)と、これまで何やってるかわからなかった人が可視化され、チームの理解がより増えるというお話。

モジュラモノリスの話はこのあとのメルカリさんでも聞いたけど、少しまとめないとまだ理解できていない。
今の理解では、マイクロサービスに行くのが本当は理想だけど、そこに急には行けないから、まずはモジュラモノリスを使って徐々に移行していきたいという話。
コードベースが巨大化すると、開発が止まってしまうため、そこをどういうふうに回避していくかという話。
大体やりたいことは事業のドメイン内で完結するので、その単位でプログラムを閉じ込めればすばやくリリースできる体制ができる。本来はマイクロサービスがよいが、そこの前段階としてモジュラモノリスがよい。
モジュラモノリスのいいところは、サービスの境界の変更が容易にできることで、サービスの境界が曖昧になりがちな事業開発にはちょうどいい。

ソリューションドメイン・・・ある程度抽象的な事例を具体化すること。(移動→徒歩で移動、電車で移動など)ソリューションドメインの大きな特徴は共通性と可変性を表せること。
ただ可変性は気をつけないと負の可変性を持ち込むので注意しなさいというお話。

PHP8は機能もりもりになったおかげで、移植がとても大変。

やっぱりここでもモジュラモノリスの話だった(行き着くところはそこなんだって感じ)BASEさんのと合わせてまとめたい。

PHPの話というか、プロセス/スレッドの話。
なんか懐かしい話がたくさんあって、再確認できた。

JSONに型をつけて、静的解析を使えるようにしよう。

composer.json, package.json, Dockerfileから依存ファイルを更新するPRを自動で作ってくれるサービス。この世界が実現できたら嬉しいけど、入れたら大変な辛さを味わうことになりそう。日頃から動作が正しいことを検証できる仕組みを用意しておく重要さがわかる。

アプリケーションのことを知るためにまずデータを取れるようにしようという話。外部/内部とあらゆる指標を取得して、そこから適切なアクションを取れるようにしましょうという話。

力尽きた。LTは復活できたらやります。

PHPerKaigi2024に参加してきました!

3年連続でPHPerKaigiに参加させていただきました。  なぜかうちのBlogに2023の感想ブログが下書きで残っているので、今年は書ききることを目標にしたいと思います。 全体の感想 会場でたくさんの方とお話させていただきました。Xでよく見かける人やPHPerKaigiでは...