トーク

PHPUnitのメジャーバージョンアップ、9.xから10.0の移行には「大きな変更が含まれている」という印象を持っている人も多そうです。
とりわけ、PHPUnit\Framework\TestCase::at() や PHPUnit\Framework\MockObject\Rule\ConsecutiveParameters() のdeprecatedについては、移行に際して不安を感じる声もチラホラと耳にします。
ここでの頭痛の種は、「今まで使ってきたテストコードを、どう置き換えればいいか」というものです。
フレームワークのAPI的な意味での「使えなくなる」ではなく、テストの意図と実現方法の見直しを促すという意味で、本当にBraaking Changeと言えます。

PHPUnitは、これまでも「利用者に適切なテストコードを書くことを促す」ように進化をしてきました。
では、 at() withConsecutive() のない世界が来ることで、我々は何を得られるのでしょう？
この変更をきっかけとして、「どんなテストが良い単体テストなのか」について考察します

伝えたいこと

• 良いテストの価値: 寿命、偽陽性/偽陰性、理解容易性
• テストコードとプロダクトコードの「疎結合」を意識する、実践する

複数のプロダクトやサービス事業を展開している企業で一度は言われる「共通基盤を作りたい」。
近年、エンジニア側も「よし、共通基盤だ！マイクロサービスを作ろう」と安易に呼応してしまうことがでてきました。このように始まったマイクロサービス開発では、往々にして失敗したマイクロサービスが負債として残り、エンジニアチームは「マイクロサービスはダメだ」という感想を持ってしまいがちです。

「共通基盤だ！」と言い出したとき、本当にマイクロサービスが必要だったのでしょうか？
前職で数年にわたってマイクロサービスを開発・運用し、PHPerKaigiでマイクロサービスを布教したこともある私ですが、現職では「共通基盤だ！」にNOを突きつけています。
共通基盤というマイクロサービスがほしくなる動機を解きほぐし、マイクロサービス採否ジャッジの基準、ニーズをマイクロサービス以外の方法で満たす方法についてもお話しします。

PHP を使っていると、予期しない、意図しない動作をすることがあります。
大抵は自分の書いたプログラムのミスですが、まれに PHP 本体のバグや意図しない挙動の変化であることもあります。
今回は "バグかな？" と思ったときの迅速な検証方法から、実際に php-src に報告を行うまでの流れを実例をもとに紹介させていただきたいと思います。
運用で回避せず、レッツコントリビュート！

privateメソッドのテストを書くか書かないか問題はよく話題にあがるかと思います。
実は、私もかつてはprivateメソッドのテストをたくさん書いていた時代がありましたが、今はprivateメソッドのテストは書かずにテストを書いています。
自分の思考の整理をするのに繋がった「単体テストの考え方/使い方」という本の内容からも引用しつつ、
実体験をベースに「なぜprivateメソッドのテストを書かないのか」というところをお話します！

トークで話す内容

• かつて私が書いていたprivateメソッドのテスト(と、その理由)
• なぜそれが良くなかったか？「偽陽性」「偽陰性」の視点から考える
• どのようにテストを書くべきだったか？
• privateメソッドのテストは書かない方がいいのか？(※経験に基づいた持論)