2021年9月第1週レポート
7月に第三子が誕生して慌ただしい毎日を送っていた、というのを言い訳に2ヶ月弱Weekly Reportをサボっていたのですが、だんだんサボること自体が苦痛になってきたので今週から復活します。
インプット
📝 この2ヶ月くらいの間やっていたいこと
社内向けの小規模なシステムをローンチしました。システムを開発/構築するにあたっての大方針としてこれまで使ったことがない技術要素を優先して盛り込むというものを設定しました。
技術選定の重要性ははよく聞きますし概ね同意なのですが、私個人としては本番運用の経験がない技術要素なんてものはそもそも技術選定時に評価することは不可能、と考えています。なのである程度のリカバリープランが用意できるのならば、使ったことがない技術要素はどんどん取り入れて本番運用での知見を蓄積していくように動くようにしています。
今回は小規模、社内向けであり、失敗した場合のリカバリープランも見えていたので上記のような方針を設定しました。
取り入れた要素を思いつくまま並べてみると次のようになります。
- バックエンド
- Azure Functions
- Azure CosmosDB
- Azure API Management
- GraphQL （Apollo Server + Azure Functions）
- フロントエンド
- React
- Material UI
- GraphQL （Apillo Client）
- 使用言語
- TypeScript + fp-tsでの関数型パラダイムの積極投入
- monocle-tsを使ったimmutabilityの追求
影響が大きいのはfp-tsを使った関数型プログラミングのパラダイムを積極投入したところでしょうか。特にバックエンドで積極的に利用しています。NodeランタイムでのAzure Functionsのエントリポイントが関数であることもあり、関数主体でのコード構成は親和性が高いと感じました。まだまだ関数型プログラミングの入り口にやっと立てたくらいだとは思うのでこれからも精進していきたいと思います。
📝 Playwrightを使い始めた
Playwright、WebアプリケーションのE2Eテストを実現するためのライブラリです。puppeteerのようなブラウザ自動操作やテストランナー、アサーション、マッチャーといったテストに必要な要素をそろえたE2Eテストフレームワークです。前々から導入したいと考えていたので今回のシステム開発にて実践投入してみました。
フレームワークとしては使いやすく効果も高いのですが、初期導入にあたってどの順番でドキュメントを読むのが効果的なのかちょっとわかりにくいなと感じました。
Playwrightのドキュメントどこから読んでいくといいかわかりにくいなと思ったら、小見出しがアルファベット順になってるんだよな。
— d_yama (@dy_karous) September 2, 2021
とりあえずInspectorを使って自動生成したブラウザ操作コードを使ってもいいのですが、テストランナーで動かしてみると動作しない、ということはよくあるので、やはり公式のドキュメントを読んだ上で使うのが一番効率が良いと思います。
ある程度ドキュメントを読んだ結果、以下の順に読んでいけば自分のプロダクトに対してテストを書き始められるのではないかと思います。
インストールから最初のテストを書くまでの雰囲気を把握できます。
Playwrightのコアであるブラウザの自動操作、現在レンダリングされているコンテンツの取得方法、Playwrightの自動待機の概要について書かれています。概要を軽く把握して以下の詳細を確認していくのが良いと思います。
ボタンをクリックする、テキストフィールドに文字を入力するといった操作をコードで実現するに当たってDOM上の特定の要素を取得すると言う処理は必須となります。PlaywrightではCSSセレクター文法の他にもさまざまなセレクターが用意されています。
また、コンポーネントの自動テストのように、E2Eテストでも最終的にDOMの状態をチェックして判定を行うケースが多いと思います。ブラウザの自動操作、アサーションの実装の両方の面でもセレクターの使い方は把握しておくとよいです。
Playwrightではブラウザの操作処理を実行する前に色々と状態チェックを行い、チェックをパスするまで待機します。状態チェックについては開発者側でコントロールする必要がなく、ブラウザの操作周りの関数はPromiseベースで実装されているのでawaitするだけで待機することができます。どの操作がどんな状態チェックを行うのかを把握しておくと、自動テストのなかでうまくブラウザが操作できないときにその原因を把握しやすくなるので、こちらも確認しておくとよいです。
判定のためにどうやって値を比較するかについて書かれています。Jestでテストを書いてあることがある人ならば、どんなマッチャーが使えるのかを把握しておけば実践投入できるかと思います。加えてPageオブジェクトのAPIとMatcherのAPIを見ておけば大体の判定は書けるんじゃないかと。
Page APIについてはこちらにリファレンスがあります Matcher APIについてはこちらにリファレンスがあります
PlaywrightもJestなどと同様にさまざまな設定項目があります。テスト実行時の開発サーバ起動、グローバルセットアップ、ブラウザのヘッドレスモードの有効/無効設定など、こんなことができればいいのに！と思うようなものはだいたい設定できる印象です。
以上の内容を把握しておけばあとはテスト実装とAPIリファレンスの確認をいったりきたりすればテストコードは書いていけるんじゃないかなと思います。
