PHPerKaigi 2020で聞いたセッションの記録です。
日次・場所
- 日次: 2020-02-09 ~ 2020-02-11 (参加したのは2日目）
- 練馬区立区民・産業プラザ Coconeriホール
余談ですが、駅近くに唐苑という、大きい黒酢豚をナイフとフォークで切って食べるランチが900円ちょっとで食べられます。
お肉が柔らかくて美味しいのでおすすめ。
E2Eテストに向き合う
スライド
Testing Pyramid
- 10% E2E Test
- 20% Integration Test
- 70% Unit Test
A Software Testing By Alister Scott
下に行くほど、テストスイート数の割合が少なくなるのがベスト
- Automated Unit Tests
- Automated Component Tests
- Automated Integration Tests
- Automated API Tests
- Automated e2e Tests
- Manual Test
手動でテストを行わなくて良いわけではなく、最終段階として手動のテストが入る。
E2Eのテストスイート数 > Unitのテストスイート数となってちゃんと理解していない人がたまにいる。
Testing Pyramidを理解しよう
Practical Test Pyramid
26 Feburuary 2018
Javaのソースコードかつ英語だけど、テストの粒度とか流れとかが理解できるので読んでみると良い。
リンク
https://martinfowler.com/articles/practical-test-pyramid.html
UIテスト vs E2Eテスト
同じものと言われることがある。
アプリケーションをE2Eでテストすることは、多くの場合UIを介してテストを実行することを意味する。ただし逆は当てはまらない。
UIのテストはE2Eで行う必要はなく、バックをスタブ化させてフロントエンドをユニットテスト化させる。
E2Eテストでは
メンテナンスコストが高いのでなるべく最小限に抑える。
ユーザーがアプリケーションで行う価値の高い部分や、中核の部分をテストする。
パフォーマンスのテストとかは見落としがちだが、E2Eテストでできる（デプロイしたら7秒かかるようになってしまったとか）。
Tools
Selenium Web Driver
今まで一番メジャーだった。
Puppeteer
Node.jsからChromeを操作。
npmでブラウザがインストールされるので環境構築が必要ない。
Puphpeteer
PHPからpuppeteerを動かすライブラリ。
その他
- jest Puppeteer
- puppetry
- Puppeteer firefox
これまでの課題を解決するPuppeteer
Webテストは遅いという都市伝説。
Browser Context APIで解決。
テストがFlakyという都市伝説。
waitforで壊れやすい。
WebDriverは判定処理がないので、Seleniumが定期的にチェックに行き結果的にタイムアウトすることがしばしば。
waitForX API で解決（Puppetterではブラウザ側で実装されている）。
どこでテストが失敗したかわからない。
Playwright
2ヶ月前くらいにマイクロソフトのリポジトリにinitial commitされる。
Puppeteerの反響を受けて作り始めた。
Puppeteerの開発チームのメンバーが何人か入ってやっている。
PuppeteerはGoogleの管理。
組織に広めるには
例えば、QAチームが毎回やっているリグレッションテストを置き換えてみる。
その上でどのくらいQAの作業が軽減されるかを事実ベースで話すのが良い。
もっと気軽にOSSにプルリクを出そう
スライド
4つの着眼点
- 作者の関心ゾーンの外側を見る
- 使っていなくてもコントリビュート
- 業務で得た知識を横展開
- ダメ元でも送ってみる
作者の関心ゾーンの外側を見る
- メインのコードの設計、実装、可読性（関心ゾーン
- メインのコードの異常ケース
- コメント、ドキュメント
- テストコードの可読性、コメント
- CI選定、環境変化への追従
PR説明欄を丁寧に書く
相手をまず肯定して、「でもうまく動かないからこうしてみたよ」みたいな感じ。
"I think" を使うと、断定より表現が柔らかくなるので便利。
ケース別の例
関心ゾーン以外
- テストコードの可読性
- パラメータの可読性向上
- 文章の間違いを修正
- 異常ケース 躊躇しないでシュッとPR作ってみるのも大事
環境変化への追従
ライブラリはほおっておくだけで古くなる
* PHPのバージョン
* PHPUnitのバージョン
* 新しいPSRが策定される
* travis.ymlにPHPのバージョンを追加したりなど
* php_cs.distを追加したり
業務で得たノウハウを横展開
- PHPUnit ver4 → ver7 にあげた
- 古いPHPUnitに依存したライブラリが多数あったりなど
使っていなくてもコントリビュート
読むだけでも見つかる
PHPStormの警告で気づいたり
ダメ元でも送ってみる
失うものはない
やった方が良いのにたまたま誰もやっていなかったケースもある
Goコンパイラ変数名をリファクタなど
PHPの現場 公開収録
PHPの現場ホームページ
最近よくご登壇される成瀬さんという方を交えた対談。
新しい書籍を出すので、その話も絡めてのインタビュー。
クリーンアーキテクチャ
チームになった時に「こういう時はこうすれば良い」の答えが出やすいよう明示されているアーキテクチャ。
10年後を見越して書くべき場所がちゃんと明示されているアーキテクチャを選定する
あらゆる層を実装しなければいけないので、普通に書いていると時間がかかる。
そこはコードジェネレーターなどを使って、エンジニアリングの力で解決する。
手数を減らす意味合いもあるけど、開発者にちゃんとしたアーキテクチャの雛形を指し示す意味合いもある。
組織に広めていくのは信頼を得て空気を作っていくしかない。
「あの人外で登壇もしてるし」などなど。
結局人と人の関係の問題。ソフトウェアは人の要因が強い。
Webとか記事でクリーンアーキテクチャに入門し、そのあと本を読むと、自分の中で「ここってこうだからだろうな」という裏付けがされた状態で本を読むことになる。
そうすると、本から得た知識が自分で考えた知識のように自信が持てる。
クリーンアーキテクチャはパターンが決まっているので、コードの自動生成と相性が良い。
DDD
書籍を出そうと思ったきっかけ。
主題はモデリングだが、パターンでつまづいている人が多い。
パターンとしてはさほど珍しいものではない。
Webだと本当に知って欲しい人たちに届かない。興味がある人は検索してくれたりしてキャッチアップしてくれるが。
Webで省いている根底にある考え方などを噛み砕いて説明しているのが今回の書籍。
人によって解釈が違うところが出てしまいやすい。
パターンとモデリングの話は別。
パターンに興味のない人がコードを書くより、パターンを知っている人がコードを書く方が害はない。
DDDのパターンを使った実装と、ドメインを中心に考える話は全く別物。
前者をDDDと言ってしまうのはちょっと恐ろしい。
よく相談受けるつまづきどころは、実装するの大変ということ。
回答としては、「コードジェネレータ作ろう」ということ。
面倒な部分はツールを作ろう。
ユビキタス言語は、お互いが意思疎通するための共通基盤としての言語。
例えば海外に行った時のボディランゲージはユビキタス言語。
どっちかの言葉でも単語でもなく、お互いがコミュニケーションを取るためのもの。
ビジネスがドメインになるので、ビジネス側の言葉を使うことが多い。
エキスパート側の言葉を開発側が使いにくかったりしたら、「使いにくいから少し変えよう」と持ち上げなければいけない。
捉え方をお互い見つめ直す。言葉の定義が揺れていないかなど。
コードを見れば業務がわかるのが理想。
コードを書くときは英語になるが、日本語との紐付けに関しては、変換Excelファイルを作ったりする必要がある。
そこは仕方ない。
知らないWebアプリケーションの開発に途中からjoinした時、どこから切り込むか
スライド
ゴール
- 途中joinについて改めて考える
- 途中joinのノウハウ共有のきっかけを作る
joinしたサービスの概要
- PHP + MySQL
- 本番、stg、共有開発環境
- 開発環境はVagrantで用意
- インフラもChefで
- 歴史が長いサービス
開発にとりかかれなかった
一通り技術スタック的には問題ない
ゼロから開発する時
- サービスの概要
- 全体のアーキテクチャを決める
- データ保持、テーブル設計を考える
- 開発環境の種類(本番,stg)
- ソフトウェア側のアーキテクチャ
の順で決める。
途中joinの場合は1、3、5を知らない状態。
「どこから切り込むか？」の回答は、「どのようなサービスか」を知るところから。
「どのようなサービスか」がなぜ必要か
開発をする上での気づきを多くするため。
機能を1つ作る時、その機能だけでサービスが成り立つだけではないため（他との連携）。
「この機能だと、こことバッティングしませんか？」など。
「どのようにデータを保持するか」がなぜ必要か
サービスの機能や実装上の制約の情報が色濃く出ているのはコードではなくデータベースのテーブル設計。
Webアプリケーションは極論してしまえばデータの出し入れ。
つまり、技術スタックの知識があったとしても、開発開始までには手間と時間がかかる。
開発開始までのオーバーヘッドを小さくすることを目指す。
開発開始までのオーバーヘッドを小さくするメリット
- 属人性が薄くなる
- サービス単位ではなく、その時のプロジェクト単位で動ける
- スペシャリストの結成ができる
削減パターン
- joinするメンバーが工夫して削減するパターン
- サービスとして削減するパターン
実践パターン事例
スコープを絞る
- 「ユーザーテーブルってどれ？」
- 「リクエストのエントリポイント教えて」
専用Slackチャンネル作る
「私が通る開発開始までの道のりはきっと次の人も通る」
閉じた開発環境を手に入れる
- メール送信機能をメール送信サーバーを使用せずできるように
- 共通データベースを使わない
その他
- デプロイのChatbot化
- マイグレーションファイル + Pull Request
オーバーヘッドをエンジニアリングの力で解決する
オーバーヘッドが小さいことを前提とした組織を作ることができる。
ここに辿り着くまでに人や工数がかかっても、最終的には開発スピードが上がって幸せになれる。
STNS
DBドキュメントのCIと周辺情報のリンクを管理
tbls
CIに組み込めるので、ドキュメントの更新忘れを機械的に防ぐことができる。
ドキュメントをMarkdown出力できる。
全体を通しての所感
- 当日の参加者120名だったこともあり、大規模カンファレンスという感じではなく、中くらいの規模で参加者同士のコミュニケーションを大切にする空気感だった
- 自動テストとかチーム開発とか、組織づくりに関するセッションが多かった印象
- 気軽に参加しやすい感じだったので、普段行きづらいと感じている方には是非来年参加してほしい
- ノベルティのトートバッグがデニム生地っぽくてオシャレだった
- 来年も参加しよう