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