Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webフロントエンドのリプレースを支えるテストの考え方 / JSConf JP 2021

berlysia
November 27, 2021

Webフロントエンドのリプレースを支えるテストの考え方 / JSConf JP 2021

JSConf JP 2021 でトークしたスライドです。

このスライドの内容を文字にしているブログ記事はこちら
https://blog.nnn.dev/entry/2021/12/03/123000

トークのアーカイブはこちら
https://www.youtube.com/watch?v=5H3Sswp5qYg&t=1155s

https://jsconf.jp/2021/talk/testing-approach-to-support-web-front-end-replacement

berlysia

November 27, 2021
Tweet

More Decks by berlysia

Other Decks in Programming

Transcript

  1. 誰に向けて話すか - これから「リプレース」をやっていこうとしている人へ - 重要な動作を壊さずに仕事をやりとげたと自信をもてるようになりましょう - テストがないところからでも多分何とかなります、実例を置いておくので参考に - 使えるものは何でもつかうために、どんなテストが役立つのかみていきましょう -

    リプレースに飛び込む前にやるべきことも示しておきます - すでに「リプレース」をやりとげた人へ - ここでは「それはそう」みたいなことをたくさん言います - こういう整理の仕方をしたんだなとか思ってもらえたら嬉しいです - こういう状況でこうして乗り切ったよ、みたいな事例をぜひ教えてください - 上記を含むすべての人へ - 多くの人にとっては普通にテストを書く上でも役に立つことが含まれていると思います
  2. 周辺の言葉 『レガシーソフトウェア改善ガイド』 曰く: - リファクタリング →コードの構造をメソッドやクラスのレベルで変更する - リアーキテクティング →モジュールやコンポーネントのレベルで行うリファクタリング -

    リライト →可能な限り高いレベルで行うリファクタリング - ビッグ・リライト - 全てを一気に書き直し、置き換える - インクリメンタルなリライト - 小さい単位でリライト、徐々に置き換える - 進め方によってはリアーキテクティングに限りなく近づく - リプレース →サードパーティのソリューションに置き換える
  3. 周辺の言葉 『レガシーソフトウェア改善ガイド』によれば…… - リファクタリング →コードの構造をメソッドやクラスのレベルで変更する - リアーキテクティング →モジュールやコンポーネントのレベルで行うリファクタリング - リライト

    →可能な限り高いレベルで行うリファクタリング - ビッグ・リライト - 全てを一気に書き直し、置き換える - インクリメンタルなリライト - 小さい単位でリライト、徐々に置き換える - 進め方によってはリアーキテクティングに限りなく近づく - リプレース←これの話ではなさそう →サードパーティのソリューションに置き換える
  4. リプレースを選ぶ条件 『レガシーソフトウェア改善ガイド』曰く、次のふたつを満たすとき: 1. リファクタリングを既に試みて失敗している - 必ず最初にリファクタリングを試みて、どれくらい効くか確かめる 顕著な改善が得られないとわかってからリライトを考え始める - コードに十分詳しくなってからの方が、リライト後へのよい洞察が得られる -

    調査的リファクタリング 2. パラダイムシフトを取り込みたい - 人材事情でのリライト、より軽量なWAFへのリライトなどが例示 - 宣言的なUI記述を中心にした思想は、これにあたるかも? - WAFべったりから独立したいというのも、これにあたるかも?
  5. よくあるつらさ - いまの開発規模に合っていない - いまの開発体制に合っていない - 世の中のデファクトから意図せず外れている - 採用の問題 -

    新しい道具に乗りづらい問題 - 安心して修正・拡張できない - ライブラリ更新がこわい - パフォーマンス改善の前にやることがいっぱい - 見通しが悪くて変更が難しい - 経緯を知っている人がいなくなって手探り - etc...
  6. よくあるつらさ - いまの開発規模に合っていない - いまの開発体制に合っていない - 世の中のデファクトから意図せず外れている - 採用の問題 -

    新しい道具に乗りづらい問題 - 安心して修正・拡張できない - ライブラリ更新がこわい - パフォーマンス改善の前にやることがいっぱい - 見通しが悪くて変更が難しい - 経緯を知っている人がいなくなって手探り - etc... その問題が解けるように よく計画しましょう リアーキテクティングくらいに 落とせるかも まず何をやっているか 調べつくした方が良い 上側のつらさに分解しよう その過程でだいぶ綺麗になるかも
  7. テストの分類いろいろ - 工程による分類 - ex) 単体テスト・結合テスト・システムテスト・受け入れテスト - 実行方法による分類 - ex)

    動的テスト・静的テスト - テスト技法による分類 - ex) ブラックボックステスト・ホワイトボックステスト - 結合度による分類 - ex) 単体テスト・◦◦結合テスト・E2Eテスト - 依存するリソースと実行時間による分類(Test Sizes) - ex) スモール・ミディアム・ラージ
  8. よく見る図:The Test Pyramid - 図に書いてあること - - この図にいま学ぶべきことは - この図を読むときの注意

    - もしより上位のテストが十分に高速で メンテナンスが容易であるならば 低レベルのテストは省いてよい The Practical Test Pyramid TestPyramid より下位のテストは実行速度が速く メンテコストも低い 結合度の高いテストはより少ない数でも 効果を発揮する
  9. 図:The Testing Trophy from Static vs Unit vs Integration vs

    E2E Testing for Frontend Apps - より下位がコスト低・高速なのは同じ - より上位のテストは より大きい問題に関心がある - 障害点が多く壊れやすい? →より多くのコードをテストしているから - エッジケースはより下位のテストで拾う より上位の実際の使い方に近いテストは より多くの信頼度をもたらしてくれる 統合テストは信頼度とコスト・速度の バランスが良いので多くするとよい
  10. 何がつらかったか 調査的リファクタリングの結果わかったことは: - JS実装の見通しが悪い - 関連する実装の凝集度が低い - 各所で機能の有無が論理的凝集によって隠れており、どこで何をサポートすべきか見づらい - CSS実装の見通しが悪い

    - 歴史的経緯が残りっぱなしの SCSSがそのまま残っている - 要素セレクタや子セレクタが濫用されていて変更に著しく弱い - 外観用の class と動作用の class が一部共通になっていて CSS を不用意にいじれない - テスト - ほぼない - 抵抗を示すような単体テストが地道に書かれていた