こんにちは！ この度、3/29（金）から3/31（日）に開催されたPHPer Kaigi 2019 にて、BASEがゴールドスポンサーとして協賛＆3名のメンバーが登壇いたしましたので、今回のそのレポートを書いていきたいと思います！
会場レポート
今年の会場も去年と同じく練馬区立区民・産業プラザ Coconeriホールにて開催されました。入り口ではロールアップバナーが出迎えてくれます。
アイキャッチ画像にもありますとおり、本当にたくさんPHPerたちが集まっていました。「同窓会のようなカンファレンスにしたい」という実行委員長の言葉もあって、PHPerたちが楽しみながら互いに交流を深める仕掛けがたくさんあり、あちこちで盛んな交流が行われていました！
トークの採択を通して選ばれた登壇者による発表ももちろん、アンカンファレンスによる突発的な発表、IRT（Interactive Round Table）による相談会（こちらも突発的なものがありました！）など、「主催者側がコントロールしてない突発的なイベントが発生してしまう」ほど練度の高いエンジニアが集まり、思う存分技術談義が楽しめるような圧倒的空間でした！（もちろん楽しいですよ！）同時にすごいエンジニアたちがこれだけ集まるのだからと、PHP界隈の盛り上がりを感じずにはいられません。
そんなPHPer Kaigiに、今回弊社はゴールドスポンサーとして協賛させていただき、3名のエンジニアが登壇いたしました！
登壇スライド
「質」の良いユニットテストを書くためのプラクティス by 東口和暉
BASE BANK株式会社 Dev Divisionでソフトウェアエンジニアをやっている東口（@hgsgtk）です。 私は、ユニットテストに関心が強く、最近のカンファレンスではユニットテスト関連の話をしているのですが、今回もユニットテストの話です。 以前、PHPカンファレンス2018にて、PHPバージョンアップと決済リプレイスを支えたユニットテストというトークで、テストの量 を増やしていった過程を話しました。今回のトークは、 テストの質 に焦点を当てたものになります。
仕事の現場で発せられる「テストの質」という言葉について「その本質・意味はなんなんだ」というなにやら壮大なテーマをモヤモヤ考えていました。途中のいくつかのカンファレンス・勉強会・ブログでのアウトプットを通じて少しずつ考えを整理していって、30分で話せる内容にまとめました。
それなりに壮大なテーマを発表したので少し反響が不安だったのですが、聴講者の方から「わかりやすかった」などの良い反応を頂いたり、はてぶやTwitterでもたくさん拡散していただいて、トーク採択から3ヶ月間、考え抜いてまとめたものが多くの人に役立つものになったことに安堵しています。また、会場で公開収録されていたPHPの現場 28. ファミコンで理解する DI（ytake）でもトークを紹介していただいてとてもありがたい限りでした。
特にアウトプットしてよかったと感じているもう一つの要素として、会場内での質問やAsk the Speakerによって多くの議論ができたことが挙げられます。せっかくなのでその際の内容を共有します。
質問・Ask the Speakerでの議論
質問：それでもprivateメソッドに対してテストしたいと思った時どうするか
「privateメソッドに対してもテストしたい時があり、テストしないということにもやもやを感じる」という疑問がありました。これについてその後のAsk the speakerにて議論なども踏まえて、3つの観点でまとめます。
1. private methodを切り出す選択肢
「privateメソッドをテストしたい」と思った時点で、そのメソッドは責務を持っていることが考えられます。そのため、「privateメソッドをテストしたい」と思った時点で別クラスへ切り出すなど設計の検討をする必要があるかもしれません。
2. どの視点を前提とするか
「privateメソッドをテストしない」という主張の根底には、オブジェクト指向という視点が前提にあり、手続き型的に考えると可視性はprivate修飾子で明示した上で、privateメソッド内の手続きはテストしたいという考え方もあるというフィードバックをいただきました。 たしかに、プログラム開発をどういう視点でみるかによってここの考え方は変わるポイントだなと感じたと共に、「プロジェクトとして何を大事にするか」によって判断が変わる可能性がありますね。
3. 変更の頻度をどこまで気にするか
「privateメソッドをテストしない」という主張の根拠として、privateメソッド自体の不安定さをあげました。しかし、テストを書いている以上、「しっかり落ちてほしい変更」もありますよね。この点に関して、落ちてほしい変更というものがある中で、どういう変更を「変更の頻度が高い」と捉えるかについての質問がありました。 オブジェクト思考の考え方の延長線上として、テスト対象をブラックボックスと捉えた上で、外部への振る舞いをテストで保証し、その振る舞いの内部で行われている処理詳細についてはテストでは検証しないという考え方が前提にあると解釈しています。 その解釈を前提とした場合、変更には「外部に対する振る舞いを変えるもの」と、「そうではないもの」という２種類が存在します。前者の変更はシステム全体の欠陥になりうるため「しっかり落ちてほしい」反面、後者の変更は「内部の処理詳細」の変更に対して落ちることになるので、「落ちてほしくない」ものと捉えられると思います。 つまり、privateメソッドの実装は、「内部の処理詳細」を担っているケースが多いため、「privateメソッドは極力テストしない」というふうに説明させていただきました。
どこまでモックするか
「不安を軽減するためのテスト」と考えると、AWS S3など外部サービスをモックせずに直接テスト対象に含めて不安を軽減したいという気持ちがあるという考え方をフィードバックとしてもらいました。これは、PHPの現場 28. ファミコンで理解する DI（ytake）でも話題に上がっていましたが、「どこまでをテスト対象とみなすのか」・「何をテストしたいのか」といったテストに対する要件から、テストの不安定さ・速度の低下といったデメリットなど様々な考慮事項を踏まえて、総合的に判断しないといけない部分で難しいポイントですね。
まだまだ、言語化できていない領域がたくさんあるので、これからも精進して継続してアウトプットしていこうと思います。
PhpStormでコードを理解する技術 by 田中孝治
BASE Product Division で技術基盤の整備を担当している田中 (@tenkoma) です。
今年初めくらいにアプリケーション開発をより容易にするため、ユニットテストをPhpStormから実行できるようにしましたが、PhpStormを使ってコードを理解するために様々な機能を使ってきたと思い、そのノウハウをまとめて発表しました。
今回の発表ではIDEでコードを理解するための技法を4つに分類したのが成果かな、と思っています。
単方向依存を実現する静的解析ライブラリのご紹介 by 川島慧
田中と同じくBASE Product Divisionで技術基盤を担当している川島（@nazonohito51）と申します。
今回は自作していた静的解析ライブラリのご紹介をさせていただきました（BASEのプロダクトではまだ使ってませんが、機会を見て導入していきたいと考えています）。元々15分相当の内容を5分に凝縮しているため「マシンガントーク」とか「いつ息継ぎしてるんだ」とか色々言われました（笑）
シンタックスの強化やPhpStormの影響で近年のPHPソフトウェアは静的構造を持つようになってきた時代であることを背景に、どうすれば設計に意識を持ってもらえるか、どうすれば設計者の意図を表明できるか、ということを考え続けた結果生まれたライブラリです。PHPという言語がサポートしてくれない領域を静的解析による力技でカバーしようとしているのですが「そうだよこれこれ、これが欲しかったんだよ」と、ありがたいことに会場内の沢山の人に興味を持ってもらえて、何人かの方の参加レポートでも取り上げていただけました。引き続き機能を拡張して、開発チーム全員が同じ設計指針を共有して開発できる環境づくりを支えるライブラリにしていきたい所存ですのでよろしくお願いいたします。
まとめ
3日間開催というおそらく開催期間という意味で国内最大のPHP系カンファレンスにもかかわらず、トラブルもなく大変実りある時間を過ごすことができました。大量のCFPへのトーク応募が殺到する中、3名もの登壇者を送り出すことのできた弊社としましても、今回のカンファレンスを大変意義深く感じております。実行委員長の長谷川様（@tomzoh）をはじめ実行スタッフの皆様方、登壇者の皆様、スポンサー企業各位、もちろん聴講者の皆様方にこの場を借りて御礼申し上げます。
