00:03
はい、9月11日、日曜日ですね。
中国は10分も回ってしまいましたね。
すみません、ちょっと朝寝坊してしまったのと、
コードを書いていたら、思ったより進んでしまったので、時間を忘れてしまいました。
はい、おはようございます。眠いなkkeeth家族の原田です。
では、本日も朝活を始めていきたいと思います。
本日はですね、昨日宣言していた通り、
今日はまたテストの記事を読もうと思います。
タイトルに書いてあります通り、
フラッキーですね。という記事を読んでいこうかなと思っております。
はい、ではでは早速ですけど、
はい、いきましょう。
ではいきます。しかも今日の記事は長いので、
たぶん明日につながる気がしています。
はい、そのところです。では行きましょう。
テストというのはツールやプロセスだけの問題ではありません。
それはアーキテクチャーの問題でもあります。
この記事では、ノーム・ローゼンサル氏の
テストを組織化し、フロントエンドとサブシステム、
そして異なる戦略の間で適切なバランスを見つける方法について、
彼の経験を共有していますというところで、
そこを読んでいこうということでした。
はい、なるほどですね。また新たな人名が出てきて、
ちょっと僕が存じ上げない方なので大変申し訳ないですけど、
でもこうやって海外の記事を読む中で、
ちょいちょい貼られている他の方のリンクとか、
他のエンジニアの人のお名前とかを教えてもらえるのにすごくありがたいので、
そこから僕はツイッターとか見に行っていて、
その人をフォローするようにしていたりはしますので。
そこから海外の方なのでずっと英語だと思いますけど、
それでも勉強になるのでね、というところです。
では続いて入っていきましょう。
私はフロントエンドの開発者、マネージャー、そしてチームが
繰り返し直面する合法的に困難なジレンマによく出くわします。
それはユニットテスト、統合テスト、
E2Eテストの間でテストをどのように組織化するか、
そしてUIコンポーネントをどのようにテストするかという問題です。
ユニットテストというのはユーザーやシステムに起きている
面白いことを捉えられないことが多いようです。
ユーザーやシステムに起きている面白いということを捉えられないということが
捉えられないことが多いようです。
またE2Eテストは通常実行に時間がかかってしまったりとか、
面倒な設定が必要だったりします。
加えて非常に多くのツール、
例えばジェスト、タイプレス、プレイラウドなどなどというのが存在します。
どのようにすればこれらをすべて理解できるのでしょうかと
ところが結構ハードルというか壁になりますよねということでした。
注意書きとしてこの記事では
例と見づけのためにREACTを使っておりますが、
いくつかの対応は任意のUI開発パラダイムにも適用されるので、
適宜読み替えてねということです。
ではでは早速入っていきましょう。
Why is testing frontend difficult?
なんでフロントエンドテストむずいの?という話ですけど、
フロントエンドというのはシステムとしてではなく、
ユーザーインターフェイスのストーリーを構成するコンポーネントや
関数の束としてオーサリングすることが多いんです。
コンポーネントコードというのは
03:00
HTML、JavaScript、CSSに分けられるのではなく、
主にJavaScriptやJSXに存在するため
ビューコードとビジネスロジックのコードが
混在しやすくなっているのも事実です。
というのは私が開発者やコンサルタントとして
出会ったほとんど全てのWebプロジェクトのことを
指していますと。
When I say weって言ってますけど
私たち、我々という場合は
私が開発者やコンサルタントとして出会ったほとんど全てのプロジェクトのことを
指していますと今回はですね。
このコードをテストしようとすると
リアクトのコンポーネントをレンダリングしてその結果をテストする
リアクトテスティングライブラリのようなものから始めることが多いし
自分たちのプロジェクトでうまく動くようにサイプレミスの
設定をいじくりまわして設定ミスで諦めることも
少なくはないよと言ってます。
よくあるお話ですね。
フロントエンドのテストシステムを構築するのに必要な時間について
上司と話すとき彼らも私たちもそれが何を見せるのか
そこでの努力が身を結ぶのか
私たちが構築したものが最終製品の品質と
その構築速度にとってどのように価値があるのかというのを正確に知らないのです。
これは多分僕ら開発者の側もそうだと思いますね。
ちゃんとその辺まで把握したりとか
その辺の数字のところまで
終えてるエンジニアってなかなかいないと思いますのでね。
さらに言うとマネージャーはテストのツールとか技術が
わからなかったり把握してる人もそんなに多くはなかったりするので
結果的に誰もわからないという感じになりそうですね。
ただエンジニアとしてはテストを書くとか実行とか
パフォーマンスがどれくらい変わるとか
数値的にどれくらい変化をするのかというか
インパクトあるのかというぐらいは何とかして把握したりとか
ある程度のメトリクスを取れるような仕組みだけでも
作っておくのは結構大事かもしれないですね。
そういうことができるエンジニアがいわゆる優秀なエンジニアと言われたりするんだろうなと思いました。
結局は技術とか開発ツールって
生み出すものとか解決したいものに対して
利用されるものなので
根本的に解決したい問題という本質なところに目がずっと向いている
エンジニアというのが重要なんでしょうねって思いました。
続いていきましょう。
ニュースレターのリンクとか
広告じゃないですけど
というのが共有されていたので
もし興味ある方はここからメールアドレス登録して
メールマガであったりとかPDFとか
フリーでもPDFとかがもらえたりするらしいので
登録してもいいんじゃないかなと思いましたね。
次にプロセスってやつですね。
チーム内にマンダトリーTDD
強制的なTDDですね。
テスト駆動開発というプロセスのようなものがあったり
さらに悪いことにコードの何パーセントを
テストでカバーしなければならないというような
コードカバレッジゲートというのがあったりすると
コードカバレッジゲートという名前がついているんですね。
何パーセントを通過しなければならないということを知りませんでした。
もっとひどいことがあります。
06:00
フロントエンドの開発者として1日を終え
いくつかのリアクトコンポーネント、カスタムフック、リアクトリデューサーズに
散りばめられた数行を修正することで
バグを修正し、その後私たちが行ったことを
カバーするためにTDDテストを考え出す必要があるのです。
まあそうね。
でもこれはTDDではないですよねというふうにおっしゃっています。
それもそうですよね。
TDDではまず失敗するテストを書くはずです。
そうですそうです。
スタートはそこから書くんですね。
しかもまずスタートはテストを書くところからスタートですね。
まさにTDDなんですけど。
しかし私が遭遇したほとんどのフロントエンドシステムでは
そのようなことをするインフラはありませんし
重要なバグを修正しようとしているときに
まず失敗するテストを書けという要求はしばしば非現実的なものなんです。
実際の現場との流れだったりフローと
バッティングするんですよね。
これもしゃーない感じはあります。
カバレッジツールとかユニットテストの義務化というのは
私たちの業界が特定のツールやプロセスに固執していることの
表れでもあります。
うーん、ちょっともやりますね。
でもカバレッジツールとかユニットテスト、義務化することは
固執しているというのもわからなくはないですけど
長期目線で見ると義務化するぐらいの
強制力で書いたほうが結果的に
品質の担保ができたりとか
やっぱり品質だよなとか
先祖ガイドとかのチェックするとか
すごく楽になって
そもそも人はテストするべきではないと僕は思っていて
人自体がバグをはらんでいるものなので
そのバグをはらんでいるものが
テストをするっていうのは正直あったりするので
テストは本来機械とかマシンにやらすべきだと僕は感覚で思っているんですね。
だからそういうツールとかユニットテストを
入れるほうがいいんじゃないかと思ったりします。
もちろんそのテストコードの品質の管理とか
コードそのものを誰が担保するのとか
そのテストコード自体の品質ですよね。
ちゃんと網羅できてるとかそのテストそのものが正しいのかっていうチェックも必要になるので
別のコースは借りはしますけど
失うコストっていうのは結構減ってくるので
僕は義務化するほうがいいんじゃないかと思ったりはしていますが
この方は特定のツールとかプロセスに骨髄していることの表れだとも言っております。
気持ちは分かります。
実際その通りだと思いますけど
でも特定のツールに骨髄していなくて
次回から見直しとか定期的に測って
ツールを変えてみるとかでも全然いいと思いますね。
その代わりツールを変えるとドカンと
正解になったりする可能性もゼロではないので
そのコストもかかりますけどね。
あなたのテスト戦略は何ですかという質問に対して
TDDとCypressを使っています。
もしくはMSWでMockを作っていますとか
ReactテスティングライブラリでGestを使っていますと答えることが多いのだそうです。
それはそもそも聞きたいことと答えがミスマッチですね。
09:00
あなたのテスト戦略は何ですかって言ってるのに
戦略を聞いてるのにツールの名前を答えられたら
それは戦略じゃないよねってあくまでツールは手段ですからね。
これはそもそも話じゃない気がしました。
もちろんQAとテストの組織が分かれている会社の中には
よりテストプランに近いものを作ろうとするところも
実際ありますと。
しかしそれらはしばしば開発とともにテストをオーサリングすることが
難しいという別の問題に到達します。
GestとかCypressとかPlayWriteのようなツールは素晴らしく
コードカバレッジもそれなりにあり
TDDというのはコードの品質を維持するために重要なプラクティスであります。
インターフェースの計画
ユニット間の関数シグネチャーとか
システムの明確なAPI
もしくは製品の明確なUI定義などなど
古き良き関心ごとの分離になりますと。
プロセスはアーキテクチャーではありませんと言っています。
それもそうだよね。
最新のツールはクオリティとか性能的にも素晴らしくて
カバレッジもしっかりあるし
Mockとかその辺のテストする時に
自動ソフトウェアテストのための欲しい機能
MockだったりSpyだったり何だったりというのは
常に組み込まれていたりするので
全然それでもいいんじゃないかという気はします。
でもそのTDDはコードの品質を維持するために重要なプラクティスである
という捉え方をしている。
この一言は割と本質をつけていていいなと思いました。
テストすることが目的ではないですからね。
とはいえ先ほど言った
カバレッジツールやユニットテストの義務化というのが
私たちの業界が特定のツールやプロセスに
固執していることの表れですというところに関して
僕自身はちょっともやるというか
果たして本当にそうかというのは思ったりはしました。
でも気持ちはすごく分かります。本当に同意です。
その後に続いた戦略は何ですかという時に
TDDとかCypress使ってますとかMock使ってますとか
リアクティスティングライブラリとJSTを使ってますというのは
戦略じゃないよねという気はしました。
じゃあテスト戦略とは何ぞやっているところはあったりはしますけどね。
ここはまた全然別の議論だったり
ビジネスの話は絶対入ってくるので
一概にこうだという一言は僕は今現時点では難しいなと思いました。
じゃあ続いていきましょう。
今のでTools and Processesの話は終了で
続いてThe Badの話ですね。悪いことです。
組織のプロセスを尊重するために
例えばCIにおける強制テストルールや
コードカバレッジゲートのように
JSTや手持ちのツールを使って変更したコードベース部分の周りを
全てMock化しそれが正しい結果を与えることを検証する
一つまたは複数のユニットテストを追加するのである。
これが悪いことの一つだと。
このテストの問題点は
コードを書くのが難しいということ以外に
自律上の契約書を作ってしまったということです。
ある関数が
期待される結果を与えるかどうかを検証するだけでなく
12:01
その関数がテストが期待するシグネチャを持ち
Mockがシミュレートするのと同じ方法で
環境を使用することを検証しているのです。
もしこの関数のシグネチャや環境の使い方を
リファクタリングしたくなったらテストは重荷になり
つもりのない契約書になります。
なるほどね。そういう意味の契約ってことか。
その機能が動作していても
失敗するかもしれませんし、内部的な何かを変更して
シミュレーション環境が実際の環境で一致しなくなったために
成功してしまうかもしれません。
要はテストコードそのものの担保というところが
次は課題になってくるような話ですね。
要は重荷ですよね。
テストコードを書くというかそのテストコード自体の
重りをしなきゃいけないというのが悪いことの
まず一つ目だということですよね。
続いていきましょうか。
その機能が動作しています。
もしこのようなテストを書いているのならば
もうやめてくださいと。時間を浪費し製品の品質と
速度を悪化させることになりますので。
改めてその悪いことをもう一回読み回しますと
例えばCIにおける強制テストルールやコードカバレッジの
ゲートのようにジェストや手持ちのツールを使って
変更したコードベース部分の周りを全てMock化し
それが正しい結果を与えることを検証する一つまたは
複数のユニットテストを追加するのですと言っています。
カバレッジが絶対的なルールになってはよろしくないし
カバレッジゲートのようなものを作って
それをCIに組み込んだりとか
全てMock化していってそれが正しいという結果を与えるような
ためのテストというのは果たして本質かどうかという
ところを取り直すのがいい話だと思います。
例えばカバレッジ90%だからほとんど大丈夫だろうと言わずに
そういうわけでもないですしカバレッジが90%だから
バグがはらんでいるでしょうというのもまた違うと思います。
そのプロジェクトとかシステムが何を担保するとか
この機能に関してどういう結果を
ちゃんと動作しています。ちゃんとバグが
エラーが発生しますというのを検証するかというところを
すごく大事なことなので。
テストって免罪符というかお守りみたいな感じで
ある意味脳死でこれさえ書いて
通っていれば大丈夫みたいなのはちょっと思われがちですけど
常にテストを書くときにはそのテストが本当に
本質とついてますかというのをしっかりみんなで見直していかなければ
むしろ悪化させることになるので無意味だよということを
言っている感じですかね。
今のがザ・バットの話でした。続いていきましょう。
続いてはですね。
ザ・コントラクトですね。
今言った契約書というのですけど
テストの良し悪しを理解する良い方法というのは
そのコントラクトを平易な英語あるいは母国語で記述することです。
コントラクトはテストだけではなく
環境に関する仮定も表す必要があります。
例えばユーザー名UとパスワードYが与えられたら
このログイン関数はOKを返すべきだみたいな具合です。
15:03
わかりやすいですね。
平易な言葉で記述することです。
コントラクトは通常状態と期待値であります。
常期は良い契約であります。
期待と状態が明確であります。
透明性の高いテストを実践している企業にとって
これはニュースではないと言っています。
当たり前のことになっているものではないですね。
しかしこのコントラクトが実際の詳細と
混同されるとさらに悪化する可能性があります。
このUseStateHookが現在14という値を保持しており
Reduxストアが3人のユーザーを持つ
ユーザーキャッシュという配列を保持している環境では
ログイン関数はホゲホゲとなります。
長いし詳細すぎるしそこは見なくていいだろうというのがあったりします。
何がどうなっていればいいのというところが
欲しい情報なので
やっぱり
状態と期待
というところが欲しいだけなのでそこだけ書けばいい。
このコントラクトは実際の選択に
大きく依存するため非常に脆いものとなります。
詳細度を上げれば上げるほど脆くはなります。
コントラクトは安定させビジネス調の
要求があるときに変更し実装は柔軟に対応させましょう。
環境から依存するものは頑丈にそしてしっかりと定義を
しておきましょうというところでした。
完全同意というか読んだ通りだなと思いました。
僕は逆に
テストのソースコードを書いたらわかると思いますが
tとかテスト関数で
ホゲホゲっていきなりディスクリプションを書くと思いますが
あれか短すぎる人もたまにいるんですよね。
そこはそれでどうなのという感じはしますので
その書き方とかルールはチーム内で
テストを書く初めのときに
定義しないといけないと思いますが
そこを決めないと皆さんが思い思いの文句を書いて
これ何のテストかよくわかんないとなったりするので
システム開発とかのプロジェクトでは
冒頭にしっかり決め事を決め倒していくという
スタートダッシュは遅いように見えますけど
最終的にはそれが一番早かったりするので
初期投資というか
導入時にしっかり時間を取るというのが重要なんですよね。
物事が進んでいないように
ステークホルダーの人もそういう風に見えるかもしれないので
そこだけちょっと課題ですけど
決め事を決めないまま走るのはどうなのという気はします。
もちろん走りながら決めればいいという人もいるんですけど
意外と走りながら決めるかというと決めなかったり
いろんな人がぐちゃぐちゃって書いたものでそのまま乗っていくか
流れたままそのままをやっていくこともあったりするので
僕は決めた方がいいんじゃないかと思ってらっしゃいますね。
では続いていきましょう。
The Flakyですね。
懸念事項の分離がうまくいかず
システム間に明確なAPIがなく
18:00
明確な署名と期待値を持つ関数がない場合
機能や回帰をテストする唯一の方法として
E2Eテストにたどり着きます。
E2Eテストというのはシステム全体を実行し
ユーザーに近い特定のストーリーが期待通りに動作することを保障するので
ありません。E2Eテストの問題は
そのスコープが非常に広いことですと。
気持ちは分かりますね。
そもそもE2Eテストの定義がそういうもんだろうって気はしますけど
結局はその定義自体が問題だというふうに
この人はおっしゃっています。
ユーザーに全体をテストすることで通常認証とか
新機能とかが生きている正しい場所であったり
リグレッションが発生した場所を見つけるプロセス全体を経て
テストケースを実行することによって
環境をゼロからセットアップする必要があるのです。
E2Eの性質上これらの各ステップは
多くのシステムに依存しており
CI実行時にどれかがダウンしたりラグがあったり
またユーザーが行っているプログラムで模倣する方法を
慎重に作成しなければならないため
予測できない遅延が発生する可能性があります。
大きなチームではこれを行うための根本原因を分析するシステムを
導入しているところもありますし
この問題に対応した
testim.ioのようなソリューションもあります。
一応testim.ioというしかもリンクが貼られているので
後ほど記事
昨日も読みました記事のリンク送るって言って送ってなかったですね
本当に申し訳ないです。
最近サボりがしたのでちゃんと終わった瞬間に送ります。
戻りますね。しかしこれは簡単に解決できる
問題ではないというのをおっしゃっていますね。
まあそれは仕方ないよねと正直思います。
いついいって名前通りにして影響するものとか環境とか
いろんなものが依存してあるので
問題はそもそもいついいやること自体の準備が大変だったり複雑なんですよ。
なので簡単には解決しないのは
それはそうだよなという問題はしました。
では続いてザグッドの話に行きましょう。
今のでコントラクトトーターバッグの話が終了したので
フラッキーの話が終了したので次はザグッドですね。
良い点です。
ちなみに今日はですね僕が朝ちょっと行動書いてて
スタートが10分くらい遅れてしまったので
もう10分くらい延長して40分くらいに終わろうかなと思っています。
では良い点ですね。
ユニットテストっていうのは制限があり
またMockを対応した環境に依存し
いついいテストはコストがかかりまた不安定になりがちなので統合テストですね。
システムテストと言ったりしますけど
しばしば良い中間の立場を提供します。
UIの統合テストではシステム全体が他のシステムから分離されて動作し
Mockを作成することができますが
システム自体は変更されずに動作しますと。
フロントエンドをテストする場合
フロントエンド全体をシステムとして動かし
それが依存する他のシステムのバックエンドをシミュレートして
あなたのシステムとは無関係なフラッキネスやダウンタイムを避けることも意味します。
それもそうだよね。
21:00
フロントエンドのシステムが複雑になりすぎた場合は
ロジックコードの一部をサブシステムに移植したり
そのサブシステムのための明確なAPIを提供することも検討してくださいということですね。
これはもうそのままですね。
完全同意というか
このままやってくださいという感じになります。
そのためにMSWとかを使ったり
JESTとかのMockを使ったり全然いいんじゃないかなと思いました。
続いて、ストライクはバランスですね。
コードをサブシステムに分離するということは
常に正しい選択とは限りまって
変更のためにサブシステムとフロントエンドの両方を更新することになるのであれば
分離が役に立たない
オーバーヘッドになるかもしれませんと言っています。
だから要法要領を守りください。
サブシステムを分離することそのものが果たして本当にいいのか
というのは常に見直しをするのがいいかもしれないですね。
変更のためにサブシステムとフロントエンドの両方を
更新することになるんだったら
確かにオーバーヘッドになりますよね。
UIロジックをサブシステムに分離するのは
サブシステム間の契約によってある程度自律的に動作するようになる場合であります。
マイクロフロントエンドというのは
正しいアプローチである場合もありますが
特定の問題を理解することよりも解決策に焦点を当てることになるので
この点にも注意が必要ですと言っています。
僕はあんまりマイクロフロントエンドという言葉に触れることはなかったんですけど
あんまりいい印象が今のところないですし
あんまりやったことがないんですよね。
これはどうなんだろうという気がしますが
もし経験持っている方があったらツイートしてくれたら嬉しいなと思います。
では続いていきます。
もしかしたら教授終わるかもしれない。
すげえサクサクするので。
続いてはUIコンポーネントですね。
テスティングUIコンポーネント、ディバイド&コンクアですね。
分割と制服と書いてあります。
UIコンポーネントをテストの難しさというのは
一般的なテストの難しさの特殊なケースであります。
UIコンポーネントの主な問題というのは
そのAPIと環境がしばしば適切に定義されていないことであります。
そのままだと思います。
リアクトの世界ではコンポーネントは何らかの依存関係を持ちます。
あるものはプロップでありあるものはフックであります。
例えばコンテキストとかリラックスの時もあるでしょう。
リアクトの世界の外にあるコンポーネントは
代わりにグローバルに依存することがよくあります。
一般的にリアクトコンポーネントの行動を見ると
それをどのようにテストするかという戦略が混乱することがあります。
UIテストはそもそも難しいので避けられない部分もあります。
しかし以下のような方法で問題を分割することで
大幅に減らすこともできますよと言っていました。
ではいくつかの方法を見てみましょう。
いまだにフロントエンドのテストって難しいですよね。
何を担保するのか、どこまでテストでカバーするのか
というのはめちゃくちゃ難しいですし
そもそもフロントエンドにロジックを持たせること自体が
僕はあまり嬉しくないと思っています。
24:00
よく言われるJSON色付け代わりという言葉がありますが
僕はそれでいいと思っていたりしています。
ただSPAを作ることが当たり前なので
多少のロジック感を持たないといけないし
大人の事情でフロントエンドで
結局ビジネスロジックを担保しないといけないという
システムはやっぱりありがちというか
往々にして要求が出てくるので仕方ない面はあるんですけどね。
なのでどこまでテストするかというのは
フロントエンドの人はしっかり考え続けていかなきゃ
いけないなと思いますけどね。
なかなかこういう議論をする場も少なかったり
やってないというのは本来必要ではなかったりする可能性もありますけど
いろんな問題がありますが
僕はでも議論していく場があった方がいいなと思ったりしています。
お前やれよって言われる気はするのでちょっと考えます。
では行きましょう。
分離する方法の一つ目ですね。
separate UI from logicなのでUIとロジックをまず分離しましょう。
コンポーネントコードのテストを容易にする主な理由は
コンポーネントコードを少なくすることです。
コンポーネントコードを見て
この部分は実際にドキュメントと何らかの形で接続する必要があるのか
それとも単体テストできるし独立したユニットやシステムなのか
を見ていくのがいいことですね。
フレームワークに依存せず
UIが使われていることも意識しない
プレーンなJavaScriptのロジックとして持っているコードが多ければ多いほど
混乱させたり不安定にしたりコストのかかる方法で
テストする必要のあるコードが少なくなります。
プレーンなJavaScriptのロジックが一番テストしやすいですからね。
またコードは
移植性が高くワーカーやサーバーにも移動できます。
UIコードが少ないので
フレームワーク間での移植性も高くなります。
ユニットテストを書いていると一番書きやすいので
JavaScriptそのもののコードだったりするので
いわゆるユーティリズとかヘルパーだったりしますけど
そういうコードは本当にテストしやすいし
コードこそテストしなきゃいけないというのも
理由としてあるかもしれないですけどね。
続いての分離は
Separate UI Building Blocks from App Widgets
アプリのウィジェットと
UIのビルディングブロックでの分けましょう。
UIコードのテストを難しくしているもう一つの点は
コンポーネントが互いに大きく異なることです。
例えばアプリにはTheAppDashboardというコンポーネントがあり
アプリのダッシュボードの全ての仕様が含まれています。
またデートピッカーコンポーネントがあり
アプリ全体の多くの場所に現れる再利用可能な汎用ウィジェットとなっています。
デートピッカーというのはUIビルディングブロックであり
様々な状況でUIに組み込むことができますが
環境から多くを要求されることはまずないよと言っています。
自分のアプリのデータに特化したものでありませんと言っていますね。
一方でTheAppDashboardというコンポーネントは
アプリのウィジェットになります。
おそらくアプリケーションの中で再利用されることはあまりないでしょう。
一度だけ表示されるかもしれません。
そのため多くのパラメータは必要としませんが
27:01
アプリの目的に関連するデータなど環境から多くの情報を必要とするようになります。
まあそうですね。
それもそうです。なのでウィジェットとビルディングブロックと言われているものは
明確に分離した方がいいよということですね。
なるほどでした。
だいたいそういうビルディングブロックって今は外部ライブラリとかに
エコシステムに頼ることが多かったりしますので
それはそれでいいんじゃないかと思いますね。
すぐはデートピッカーに関しては外出されているライブラリを導入することが
今はデファクトだと思っていますので
あれを自前で作るってめちゃめちゃ大変そうですからね。
続いていきましょう。
UIのビルディングブロックをテストするですね。
テスティングUIビルディングブロックです。
UIビルディングブロックっていうのは可能な限りパラメトリックであるべきであると言っています。
それらはコンテキスト。
いわゆるグローバルだったりリラックスだったりユーズコンテキストですね。
あまり多くを引き足すべきではないので
コンポーネントごとの環境設定という点でも
多くを必要としないはずですと言っています。
これは完全同意ですね。
パラメトリックなUIビルディングブロックをテストするための懸命な方法というのは
一度環境をセットアップし、例えばブラウザーとその環境から
必要なものをセットアップしておいて
そうすることなく複数のテストを実行することですと言っています。
これもそうですね。
しっかり環境を用意すれば一発で行けますよねってことでした。
あとちょっと。すみません。あとちょっとなので
40分若干お待ちします。申し訳ない。
続いてがラストですね。
テスティングアップウィジェットですね。
アップのウィジェットをテストしましょうと。
アプリウィジェットっていうのはパラメトリックというよりも
コンテクスチュアルです。
ちょっとすみません。なかなか使わない英単語なので
神々ですけど。コンテキストに依存するような形になる方が
プレジェットとしていいよと言ってますね。
通常環境から多くのことを要求し
複数のシナリオで動作する必要があります。
しかしこれらのシナリオを異なるものにするのは通常データまたは
ユーザーインタラクションの何かですと。それもそうね。
UIビルディングブロックをテストするのと同じように
ウィジェットをテストしたくもなります。
異なるフックを全て満たすような偽の環境を作ってその結果を確認するのです。
しかしそのような環境はやっぱり脆くなりがちで
アプリが進化するにつれて常に変化し
テストはやっぱり陳腐化してウィジェットが何をすべきなのか
不明確なもしくは不正確な見解を与えることになってしまいます。
コンテキストコンポーネントですね。
をテストする最も信頼できる方法というのは
その真のコンテキスト。つまりユーザーから見た
アプリの中で行うことがそのコンポーネントになります。
アプリのウィジェットをUI統合テストや
ときにはE2Eテストでテストします。
しかしUIの他の部分やユーティリズを目隠し
わざわざユニットテスト化する必要はないよとも言っています。
そこはテストの流度と分離のところを
しっかり分けたほうがいいと思います。
この記事内のリンクとして画像が貼られているんですけど
30:01
チートシートですね。
チートシートが貼られているのでそれを見ながら
適切に分離したりこういう風に分けましょうというのが
今読んできたやつが全部バッと一言でまとめられているので
それも見てもらうと分かりやすいと思いました。
最後サマリですね。サマリガッと読んで
今回出せなかったら終了したいと思います。
翻訳がんばれ。はい翻訳が来ました。
最後ようやくですね。フロントエンのテストが複雑なのは
UIコードが懸念事項の分離という点で
ビジネスロジックのステートマシンというのは
フレームワーク固有のビューコードと絡み合い
コンテキストを認識するアプリウィジェットは
分離されたパラメトリックのUIビルディングブロックと絡み合います。
コンテキストを認識するアプリウィジェットは
分離されたパラメトリックのUIビルディングブロックと絡み合います。
全てが絡み合っているとき
唯一の信頼できるテスト方法というのは
不安定でコストのかかるE2Eテストにおいて
結論が変わらなかったのね。
この問題を解決するには
特定のプロセスやツールではなくアーキテクチャに依存することです。
ビジネスロジックのフローの一部をビューを問わないコード
ステートマシンなどに変換するとか
ビルディングブロックとアプリウィジェットを分離し
それぞれ異なる方法をテストするとか
フロントエンドの他の部分ではなくバックエンドとかサブシステムを模型しましょうとか
システムの署名と契約について何度も何度も考え抜く
あとはテストコードに敬意を払いましょう
これいい一言ですね。テストコードに敬意を払いましょう
テストコードはコードの重要な一部であり余計なものではないんですよ
フロントエンドとサブシステム
そして異なる戦略の間で正しいバランスを取ることは
ソフトウェアアーキテクチャの技術になります。
それを正しく行うことは難しく経験を必要とします。
このような経験を積むための最良の方法は試してみて学ぶことです。
やっぱりそうなるんですね。
学習の助けになれば幸いです。
ベンジャミングリーンバウムと
ヨナサンデニブの
技術的な側面から
この記事をレビューしてもらって感謝しています。
以上でこの記事は終了します。
意外と強度が上がりましたね。
こういう記事を書くときにいろんなテクノロジーの人から
レビューをもらうというのも結構素晴らしいですね。
そうやってレビューをもらって最後に記事についてサンクスをもらうことも結構多いので
僕みたいに適当にバーって書いてとりあえず出してみて
あとでまた借りもらって修正するみたいな人ではないというところが
さすがだなと思いました。
はい、では以上でフロントエンドですね。
テスタブルフロントエンドという記事を読んできましたけどいかがでしたでしょうか。
僕はめちゃめちゃよかったですね。
昨今テスト系の記事いろいろ読んできたんですけど
ダントツでトップですね。
あくまでフィロソフィーというか
マインドセットに近いところもあったりするので
だいぶ抽象的なお話ではあるんですけど
少なくともうちのフロントエンドのメンバーに読ませていけなくて
33:00
僕はよかったなと思います。
皆さんがどう感じるかは別ですし僕の観点ではありますけどね。
参考になれば幸いです。
長くなりましたけど今日の朝方はこちらで以上にしたいと思います。
日曜日ですね。しっかりお休みいただければなと思います。
今日も昨日と一緒で技術書店やってるそうなんで
興味ある方は行ってみてもいいんじゃないかなと思いました。
今日はご参加いただいて
いつも参加いただきありがとうございます。
また明日もゆるい記事読んでいくので
参加いただければ幸いです。
では終了します。お疲れ様でした。
