トーク

PHPUnit もバージョン 9 になりました。長年第一線で活躍し私達PHPerにテスト可能な開発環境を提供し続けてくれているPHPUnitは、その分歴史が長く、バージョンごとに これまでの使い方は deprecated になっていきます。

PHPUnit 9 では、さまざまな機能削除や非推奨勧告がありますが、その一つが表題にある MockBuilder::setMethods の deprecated です。

そこで改めてこの変更を機に、次の点を抑えていきます。

• PHPUnitのTestDoubleの語彙整理の根拠 xUTP本とその該当箇所、createStub / createMockの違い
• setMethodsからaddMethods/onlyMethodsになった使い方
• deprecatedになった理由をissueの内容から抑えて背景思想を理解する
• PHPUnit の内部実装ではどのような変更が行われたのか（これはPHPUnit 8でのaddMethods/onlyMethodsの話でもある）

AWS ElasticBeanstalkで運用しているサービスでAWS SQSとLaravel Jobを用いたWorkerサーバーで不具合が発生した。

Jobの実行が必ず失敗するわけではなく、なにか特定の条件があった。
それはスペースが2個以上ある場合のメッセージQueueだと特定した。

この不具合に対してどのように改善したか説明します。

皆さんの開発現場はAPIドキュメントの自動生成化がお済みでしょうか？
このLTではCakePHP4にSwaggerを導入して、コードのアノテーションからドキュメントを自動生成するまでの流れをご紹介いたします。

▼こんな方におすすめ
・これからWeb API開発を始める方
・ドキュメント書くの面倒な方
・実装とドキュメントの乖離に苦労したことがある方

昨年、社内で実施した勉強会のテーマの中で一番メンバーの反応が良かったのが「アノテーションからのドキュメント自動生成」でした。ドキュメント作成の手間を少しでも減らして、開発体験を向上させていきましょう！
（LTではCakePHPをサンプルコードとして紹介いたしますが、Laravelに導入する手順も別途資料をご用意させていただく予定です。）

チームで開発する際には、プログラムの整合性を担保ためや一定のコード品質を満たすためにコードレビューを行うことがほとんでです。
社会人になって、自分の作成したコードをきちんとチェックされるという経験をする新卒エンジニアも少なくないでしょう。
最初は粗だらけのコードでも、上司や先輩のコードレビューをもらい修正することで、一定水準を満たした状態でアプリケーションに取り込まれます。
しかし、上司や先輩のコードレビューの手間や作成したコードの手戻りの手間を考えるとどうでしょうか。
コードレビューを受けて多くの指摘をもらったときに最初の内はなぜ指摘が多かったのかや、
今後、どのようにコード品質改善していったらいいかわからないという人も多いのではないでしょうか？
そこでコード品質を改善するために、どのような種類の指摘が多かったのかを振り返り、
セルフチェックリストの作成したり、ペアプロをおこなったりすることで
その結果、コード品質を向上させるために必要な観点を得ることができました。

社会人1~2年目でコード品質を改善する中で行ったことや気づきたことを紹介し、
社会人になったばかりの人や新しく社会人になる人の助けにしたい思います。

「コード生成？なんか難しそう。人力で頑張ってコード書いチャオ！」
なんていうふうに思ったことはありますか？
単純なPHPコードであれば結構簡単に生成できるんです。

コードが少なくてシンプルであることに越したことはないですが、
開発する対象やPHPの制約のために似たようなコードをたくさん作らなくてはいけないケースがあると思います。
そういう時に役に立つのがコード生成です。
PHPの基本的な機能を使ってお手軽にコード生成する方法を紹介します。

自分は今、とある Laravel プロダクト２件で "Fargate 化" に取り組んでいます。
両方ともまだリリースには至っていませんが、現時点でも数多くの壁とぶつかり、
その度に乗り越えられたり躓いたりで一喜一憂を繰り返しています。

2021年3月時点での、この道のりで得たFargate化の意味や乗り越えてきた障壁を、
共有できればと思います。

皆さん、開発・運用では様々なツール、コマンドを駆使していると思います。
また、利用者もエンジニア、デザイナ、QAなど多様で、環境もローカル開発用PC、ステージング/本番サーバなど用途に応じてOS、プラットフォームを使い分けていることと思います。
そこで、makeコマンド(Makefile)で開発・運用をもっと楽にするための幾つかのノウハウを紹介いたします。

• 複雑な操作、一連の処理をまとめてタスク名をつける
• 必要なことだけをやる (依存関係、タイムスタンプ)
• 環境の違いを吸収する (開発/本番, Mac/Windows/Linux, etc)

※ phpに限定しない、汎用的に活用できるテーマです。

単体テストを作り込んでいくと、「データベースを使う部分をどうするべきか？」という悩みにぶち当たる場面があると思います。
「そもそも”コードのテスト”なのにデータベースに依存するなんて」や「どうしても全体実行に時間がかかるな」などです。

そこで、「vimeo/php-mysql-engine」という選択肢はいかがでしょう？

前口上

丁寧に、クリーンな構造を持ったアプリケーションであれば、その辺りはモックやスタブを利用しながら、「データベース接続」についての一切の関心を外に追いやったテストも可能になるものかと思います。
他方で、「そこまで行っていない」アプリケーションも多いでしょう。
いずれにせよ、既存のアプリケーションやフレームワークといったコードベースに、大幅な手を加えず、それでも「もっとライトにテストを回す」という願望は叶えられないものか・・・

本題

vimeo/php-mysql-engineは、実際のMySQLデータベースを用いずに、(PDO_MYSQLを想定した)RDBMS処理を再現できるライブラリです。
vimeo/php-mysql-engine - Packagist

既存のアプリケーション構造が、リレーショナルデータベースと疎結合にできる”testable"な状態になっていなくても、
php-mysql-engineを利用すれば少ない工数で「自動化テストの効率化」を狙えるかも知れません。

このトークでは、ライブラリの簡単な紹介と、実際にテストに組み込むにはどうすればいいか？を紹介します。

phpinfoは、インストールする時によく使いますね。
それがどのように動いているのか知りたくなったので、phpinfoを写経してみて、わかったことを共有したいです。