ep.113『おすすめツールから QA との協業まで End-To-End テストのイマを聞いてみた』 | UIT INSIDE

2022/03/04 に公開1592 views

このエピソードについて

@potato4d が SET チームのテストエンジニア @Isao に、E2Eテストの最新情報について話を聞いてみました。

自己紹介

Isao
- SET チーム
- テストエンジニア

テストフレームワークの進化

全体的に技術の進化によってペインポイントが解消されつつある
- smart wait
- semantic selector
  - css(element, class, id) -> data-* attribute -> text locatorの変遷
  - 最近はReactやVueのComponentを対象にしたSelectorも
    - playwright など
- ブラウザ操作 + assertion + reportingが熟れて来た

気になる技術

Playwright がイチオシ

puppetter はフロントエンドエンジニアなら誰もが使ったことがあるはず
- とはいえあのツール自体はブラウザの自動化が主眼
- ローコストで E2E をやりたい場合は、素直に専用のツールを使うほうが良い
Cypress はどうか
- 良いツールだが、比較的クセがある部分も多い
- Easy にメンテナンスするなら Playwright がおすすめ
Experimental な機能が魅力的
- React/Vue のコンポーネントを Selector として利用できたり
- Production 品質だと難しいが、開発者側で使うくらいなら問題なく使えるくらい

QA との関係

End-To-End ができるとコストを削減できるという考えは幻想
むしろコストをかけてでも将来に向けての品質を担保するためにやっておくべきものと考えるべき

Refs

LINE 新卒採用 2023
- https://linecorp.com/ja/career/newgrads/engineering/
キャリア採用はこちらから
- https://linecorp.com/ja/career/position/475
BGM&SE
- 魔王魂/騒音のない世界/OtoLogic

採用について

使用素材・クレジット

BGM&SE

音声書き起こし

1. オープニング 00:00

@potato4d 00:04
こんにちは、UITのpotato4dです。え、ユーザーインターフェイスとテクノロジーを愛する開発へのウィークリーポッド、キャスト UIT INSIDE。今週も始めていきたいと思います。今週はですね実はこれまでuidインサイトで1度もピックアップしたことがなかった。エンド2、エンドテストeteテストの部分についてですね。

@potato4d 00:23
えいさんに出演いただいて、話を聞いていこうと思っております。えいさん本日はよろしくお願いいたします

@Isao 00:30
よろしくお願いいたします。

2. 自己紹介 00:39

@potato4d 00:39
では、早速。いさおさん今回いいテンサイド初出演ということになるんで。せっかくなんで、自己紹介の方お願いしてもよろしいでしょうか。

@Isao 00:48
はい、わかりましたえ、皆さん初めましてえ、LINEoのえ、settmに所属するsetのえいです。本日は、テストに関するお話をさせていただくということで、え、出演がいただきました。今のこのftになる前は、え、ハーバーファイルのAPIのエンジニアをしていて、今はLINEで、

@Isao 01:10
専門はAPIのエンドエンドテストを担当しているんですけども、そこに限らず、え、フロントエンドやpiやcadについてのえ、整備やメンテナンスとかについてもえ、担当しています。え、本日はよろしくお願いいたします

@potato4d 01:25
かなり幅広く担当されてる感じですよ。

@Isao 01:28
そうですね、割となんでもやなところはあります。

@potato4d 01:33
では、ちょっと色々聞いていければなと思いますので、本日はよろしくお願いいたします。

@Isao 01:38
はい、よろしくお願いいたします。

3. 最近の End-To-End テスト事情ってどんな感じ？ 01:41

@potato4d 01:42
では、早速本編に入っていきたいなと思っているんですけども。ですね。今回、ちょっと勇本さんにお話を聞きたいなと思ったのが、ちょっと今回の収録を相談させていただくえ時にもお話した通り、ステートofjsの方で、結構eteテストが注目が

@potato4d 01:58
集まっているなという風に感じておりまして。えま。かなりフロントエンドの中でも、まあ、ユニットテストはこれまでもかなり書かれてきていたり、コンポーネント単位でのえ、スペックを格みたいなことは浸透してきた一方で、まあ、ちょっとイツテストとかも関心が上がってるのかな。思いまして。なんかただ一方で、やっぱりフロントエンドエンジニア支店でいうと、かなりこう。複雑化してきているspaのにテストってこうメンテナンスコストが高かったりだとかまうまくワークしなかったりとかっていう風な印象が。

@potato4d 02:27
やっぱお強い人も多いのかなと思ってて、私自身結構なかなかこう費用対効果とか考え出すと、なかなかこう手が出ない領域ではあるんですけど、まあ、結構そういうところって、もしかしたら変わってるのかもなとか思ってきたいなと思った次第なんですけど、なんか最近最近って言ってもこうかなりざっくりな感じになっちゃうかなと思うんですけど、なんかこう近頃の逸テストって、なんかそういうペインポイントとかが改善されていたりとかするんですかね。

@Isao 02:55
そうですね、そういう意味でいくと、やっぱこう。エンドトレンドテストのような、色んな外部環境とか、依存関係に影響される。テストってのは、やっぱりメンテが難しかったり、やはりユニットテストにえ比べて、アインドトレンドテストのテストコードとか、テスト環境っていうものはまだ比較的新しいものなので、ベストプラクティス

@Isao 03:17
があまりえ見つけづらいというか、え、なかなかないような状態があるので、なかなかうまくいかない事例というのは、あと僕の方でもよくえ話は聞いています。最近ではなく、昔の話からになっちゃうんですけど、も、はい、昔だとドムのこの要素とか、え、このクラスのエレメントを取得してクリックするみたいな。ま、基本的なブラウザ操作のAPIを使って、あ、それと

@Isao 03:44
え標準のテスティングフレーマークのjユニットとか、ゼスだともかとか、ェストとかはいと組み合わせて、エンドトレンドテストの自動テストっていうのは、えーされていたんですけど、もまそこの辛いところは、やっぱりそのブラウザとかの挙動によって、あのページのロードが遅かったりだとか、なんか、ロムが変更されることによって、テストが簡単に溶けてしまうっていう問題はま、昔から指摘されていて、

@Isao 04:10
それに関して言うと結構最近はえ。まあ、そういうペインポイントを解消しようと、フレームワーク側で、え、頑張っているところがありまして、例えば、まあちょっと前だと。あの、まあcssあのidとかえ、クラスとかを使わずに、え、専用のデータアトリビュートデータ配布テストみたいなトリビートつけよう。

@potato4d 04:33
ああ、結構そうですね、なんかは割と私たちもそれでデータデータテストidみたいなものを専用でやることによって、指先生の変更に左右されないみたいなの

@Isao 04:46
だって、そこで1つデザインからの分離っていうのができていて、

@potato4d 04:51
ただ、それは

@Isao 04:53
え。それとしても、ただ、そのデータのアトリベートを入れるのって、基本的にはコーリングをしてる人にしか入れられないので、例えば、すごく分業しているフロントエンドエンジニアとえ、テスト自動化エンジニアとか。あ、qaaのえ、誰かがやるとかっていうパターンもあるんですけども、そういうところだと、なかなかそこのコミュニケーションコストが大きくて、

@Isao 05:16
ちょっとここにこのアトリビュートを追加してくださいとかお願いしして、追加して、デプロイしました。じゃあ、ちょっとテストコードを動かしてみますね。みたいなコミュニケーションになったりしてしまったり、あとは、最近だとリラクトやえーなどのえ、フレマーク、えーを使っていたりすると、

@Isao 05:36
コンポーネントというか、ドムの狙った位置にそのアトリブとつけられないっていう問題もあったりして、なんかああ、ちょっとここクリックしたいんだけど、ここのどぶにこのエレメントにつけれますか。って言われたら、いや、ちょっと。これは自動生成されてるサードパーティのものなので、難しいですね。ああ、話があったりするんですね、

@potato4d 05:54
結構逆にあの自分たちで書いてるコードベースだと、フレーマークの方がそういうの設定しやすいかなと思いますけど、逆に、エコシステムっていうところになると、つけづらいみたいなのは、え、確かにありますね。はい。

@Isao 06:06
エンジニアがコントロールできないレベルの小さい要素とかになってくると、なかなか難しいところがあるんですね。で、その中で。自動テストで、そのフレームワークでいくと、サイプレスとかコードセットジースっていうのは、これ、スケートオジースでも言及されているものであったと思うんですけど、とま、

@Isao 06:26
例えば、ユーザー登録フォームとかの登録ボタンを押すっていうようなえ曲をしたい時に、このボタンをエレメントをしてするというよりかは、投資とか登録っていう文言を見つけて、これをインナーテキストに持つエレメントプリックするみたいな。ああ、ちょっとふわっとした。はい、規定方法っていうのができるようになってきていますとは

@Isao 06:49
ま、そのふわっとした指定方法も、その1つのページ単位で行くと、なんか同じ単語っていくつもあったりして、じゃあどれだみたいになったりするので、そういう時は、先ほど出た。データとのアトリートとか、cssエレクターを組み合わせたりと、サイプレスで言うと、まず先にちょっと広い範囲。例えば、ホームの

@Isao 07:13
両子を指定して、その中の登録ボって書いてあるボタンをクリックするみたいな。あ、あ、はい、絞り込みみたいな指定方法ができたりするんですね。そういう形で絞り込むことで、多少ロバストなえ、設計でテストコードが入ったりできるようになってます。

@potato4d 07:30
なるほど、じゃ、かなりま書き味の方もいいの方でもよくなってきてるって感じなんで、はい

@Isao 07:35
はい、良くなってきてる感じですね。ふわっと

@potato4d 07:37
こうそういうこう厳密じゃない。テストの書き方とかって、最近だとリアクトだったら、あのテスティングライブラリーとか、コンポーネントのテスト。でも、だんだん取り入れられてきてるかなって考え方かなと思ってたんですけど、かなりいがそういうのに寄ってきてるんですね。

@Isao 07:51
そうですね、寄ってきてますねで、そうやってちょっとセマンティックな感じのセレクターのいいところは、テストコード自体がなんていうか、自然なテストケースになってくれるんですね。と、手動テストで、テストシナリオを書いた時には、登録ボタンを押すっていう形にかかれたりすると思うんですけど、ベストステップがはいはい、それと、似たような感じの書き味でベストコードがかけたりするので、結構見通しが良くなるんです。なるほど、なるほど、

@Isao 08:18
見通しが良くなるま、ちょっとあんまりコードコードしてないような。はい、テストコードになるので、そういう意味だとノンコーダーであるqaとか、pdmとかの人にも見てもらえる可能性はあ

@Isao 08:30
とは思っています。

@potato4d 08:31
あ、結構う宣言的と言いますか。そうですね、はい、こうコード上のコードベース自体に詳しくなくても、これだけを読むとこう疑似コード的に伝わりやすいような感じになってるんですね。

@Isao 08:43
そうですね、はい、デコード的なものでいうとと、9カバーとか、えェブとかかな。dddとかに寄ったようなフレームワークだと、ビジコードというか、まあ、ちょっと自然言語っぽいものと、そこに対応する。テストコードみたいな組み合わせってのは過去にはあるんですけど、今だとそれがまあ一緒になってる形ですね。で、これが洗面的で人間が読める形、かつ

@Isao 09:09
機械を認識してブラウドを操作してくれる。あ、もしくは、ささしてくれるっていう形になりますね。

@potato4d 09:17
あ、じゃ、かなり進化してるん。

@potato4d 09:21
ほんとに変更に強い感じにはなってきてるんですね、なって

@Isao 09:26
来てますね、

@potato4d 09:27
はい

@Isao 09:29
で、あと、ちょっとこれはあまりいわゆる実際の環境では使いづらいところあるんですけども、リアクトやビーのコンポーネント、はいはいをアイデンティファイヤーとして、セレクトできるような機能ってのが、例えばプレーライト。ああだと、今ちょっとエクスペリメンタルなんですけども入ってたりするので、

@Isao 09:51
ちょっと。そのフロントエンドエンジニアの中だけで、ちょっとちょこちょこやりたい。あの、開発中にちょっとさいじりたいっていう時には、そこのセレクターってのは、結構ま書いてるコードと、直感的にリンクしやすいようなセレクターっていうのが出てきてます。

@potato4d 10:07
結構今はまだまエクスペリメンタルっていうのもあって、実用でかめにはできないとはいえま。結構開発中とかであれば、

@Isao 10:14
ガンガンいじれそうですし、そのフロントエンジニアえ、なんていうか、フロントエンジニアの取っ掛かりとして、そのテスというか、まあ、ブランド操作したいとかいう時が結構いいかもしれないですね。あ、

@potato4d 10:28
それはかなりこう。フロントエのエンジアシェからすると嬉しい進化ですね。

@Isao 10:34
そうですよね、自分たちの書いてるコードと近いもので、書けるっていうごくいいと思

@potato4d 10:40
ありがたい限りですね。はい、ちなみに、今のセレクターの話で言うと、なんかあのフロントエンドで言うと、あのウェイアリアとかで、あのアリハンドラみたいなんで、最近出てきてるかなと思うんですけど、あの辺りはいの考えとかも結構イツの方でも、こう積極的に今だといろんな技術で使えたりするんですかね。うん、

@Isao 11:01
はい、これはペキリアだったかなと思うんですけど、はい、エリアハンドラーで記述したり、とまろォーマットというか、クエリで記述できたりとか、そういうのも出てきてるとはありますね。

@potato4d 11:12
結構この辺りは、あのこっちベースにすることもできるし、まあ、さっきおっしゃってた。そのこのテキストがある場所みたいな、なのもま、専用のそれぞれの技術であるようなものも使えるし、感じで感じで柔軟にではいるですかね。はい

@potato4d 11:28
はい、

@Isao 11:29
こういった戦術っていうのをま、戦略レベルと誰が書いて、誰がメテして、誰がそのデビューするのかっていうところをベースにして選択していくのがいいかなっていうのは思ってます。多分、そのエリア、ハンドラとかを多分、ノコーダの人から見ると、ちょっとうん、どこだ。確かに

@potato4d 11:46
確かに思うので、

@Isao 11:48
そこはやっぱそのチームとか、そのチーム内でのロールとかに合わせて、え、選択するぐらいのちょっと幅が広がってきたなっていうのは、もう

@potato4d 12:00
かなりもうあの、いろんな人が去りやすくて、まあ、メンテナンスコストも比較的低くはなってきてるんですね。はいえ、

@Isao 12:09
だいぶそこの安定感っていうのは増えてきましたし。あと、そうですね、そのブラウザ操作でよく辛いのがそのクリックしようと思っても、その要素がまだ量がされてない。はいはいはいにウエイトとか0.5秒入れてみるか、3秒待つかみたいな。あの買って、昔はちょっとそれがそんなに多くなかったんですね。っていうのも、やっぱり、リクエストごとにページがもうまそうにロードされたりとか

@Isao 12:35
いうページ遷移っての発生したんですけど、先ほどおっしゃってましたけど、もまstaとかえ、ガンガンえ、主流になっていく中で、部分的に非同期にリロードされるようなものが増えてくると、ウエイト祭り、スリープ祭りになっていわれますね。で、そういうのをええ、昔はそのローテスト、エンジニアが

@Isao 12:57
職人技とかまちょっとヘルパーカス使ったりしてやってたりしたんですけど、今は、フレームワーク側でオートウェイトとか、スマートウェイトって言われ方しますけど、ま、実際的にはコーディングを行って、この要素が見つかったら、一定時間内で見つかったら、く。

@potato4d 13:14
ああでま台湾としたら、普通にエラーになる

@Isao 13:17
エラーになるって感じですね。はいっていうような形になってるので、行動を書く上では、そこはあまり気にせずに書けるようになっていますし。で、ホントのタイムアウトもそこまで短くないので、そもそもタイムアウトしてしまったら、ちょっとそれをまず uiというか、uxから考え直してみようかって話ができるかなと。

@potato4d 13:36
いまあ、じゃあ結構こうフレーキなテストにはなりづらい仕組みが

@Isao 13:47
直してとかま、フレームワーク側で吸収しようとかっていうような動きがというか、流れが結構うんと、まあ、成熟してきた感じはありますね。まだまだ完璧ではないんですけども、それでもだいぶ良くなってると思います。

@potato4d 14:04
なるほど、じゃかなりこう、メンテナンスであったりとか、そのテスト自体の信頼性担保っていうのは、かなりしやすくなってると、

@Isao 14:14
そうですね。テストコードそのものに関しては、結構こう成長してるなっていうのはありますね。はい、

@potato4d 14:21
ちなみにもう1点、そのメンテナンスコストで、結構おっきな点がフロントのエンザであるなと思ってるんで、ちょっとそっちもお聞きしたいんですけど、はい、あのこう古き良きmpaと言いますか。あの、いわゆるそのビルがべったり、紐づいてるようなアプリケーションから、こう。spaになった時に、なんか、私たちの私が今担当してるプロジェクトとかもそうなんですけど、あの、そもそも、フロントエンドとサーバーのリポジトリが分かれていて、あの

@potato4d 14:49
試合とかで1位とか動かそうと思うと。例えば、レイルズアプリケーションとかだったら、dvクレイとして、マイグレーションして、そっからテストも流すんで、毎回こうクリーンな状態で。で。で、なんかあのま、そのシートデータだけ入ってる時にいができるとかってあったかなと思うんですけど、結構そもそも、フロントとサーバーがリポジトリ分かれてると、フロントエンドでいするためには、こうサーバーうんも必要で。ただ、サーバーの方に依存するのも、それはそれでなんかおかしいしみたいなので、結構こう。

@potato4d 15:18
そもそも、どうやって踏み出したらいいんだろう。まあ、モックでいいのかな。みたいなのって悩みとしてあったのかなと思うんですけど、その辺りってなんかこう変わったりとかしたんですかね。

@Isao 15:29
最近そうですね、今で言うと、フレームワーク単位で、なんかすごいブレークスルーが出たぞっていうところまでは言ってないんですけども、今の環境でいくと、ロッカーや、クーバネテスが結構普及してきてる中で、まじゃ、例えば、そのまモックとその実際にデプロイされてるサーバーアプリケーションは、いと、あと、そのわ、その後ろ側のデータベースの間ぐらいの

@Isao 15:57
信頼性を持ってるサーバーのアプリケーションのコードベースは、物価イメージとして用意して、あとはまあそのえ、仮のデータベースみたいなのも、どっかイメージで提供して、これをフロントエンドから使うっていうような使い方をしている。ああ、そうな形でのえ、テストってのは海外でもありますし、社内でもえ、いくつか例はあります。あ、

@potato4d 16:19
なるほどやこれまでやっぱ都全部フロントのしのテストのために構築するってのが大変だったところがま、根本的な解決はまだしてないけれども、こうくね。テストかで、まっと環境を1個作りやすくなったんで、そこに対してテストを流すってのができるようになってきた。

@Isao 16:36
はいはい、そういう形ですね。共有環境でにしか接続できなかったのは、そのテストに閉じたりとして用意できるようにな。

@potato4d 16:45
それはすごいいいですね、

@Isao 16:49
はいで、理想的には、例えばそのサーバーサイドのサーバーサイドのAPIとして、安全なそのインテグレーションテストというか、APIのテストある程度自動化されたテストがあって、そこの動作が保証されたものがま、フロントエンド用の一テストに提供されているという形になると理想的ですね。ああ、確かに確かに

@potato4d 17:10
あ、でもなんかそういうのもかなりやりやすくはそう

@Isao 17:13
はいねなってるで、結構その辺をプラクチは結構最近増えているところであります。

@potato4d 17:19
ちょっと車内でいい事例とかあったら、

@potato4d 17:21
ベット書いてないんですね。

@Isao 17:26
車内でいくと、フロントとサーバーが同じリポリトリにある状態だと、もう完全に1つの車によって、スクラスターに閉じて、フロントのサーバーのデータベースのデプロイしてやってしまおうみたいなことがあまいくつか、ちょっと試しているとこはあります。

@potato4d 17:41
こい、それは組まれてとかのおかげでやりやすそうですよね。そうやり構築して、テストが終わったら落としたらいいって感じです。

@Isao 17:48
したいっていうのもありますし、まで残しておきたかったら、残しておけるしっていうな。そこら辺のフレキシビリティーが高いですね。

@potato4d 17:56
いいですね、じゃあ、結構このあたりもまあやりやすくはなってきているっていう感じ。

@Isao 18:02
そうですね。やりやすくはなってきていますけども、あそこがこううまくフレームワークとか言語でカバーできていないので、そのあたりは、実際に自動テスト環境を構築する人のスキル次第のところがある状態ですね。

@potato4d 18:16
結構あれですか。あの、いさんのsetのチームの方で、そういったところの支援を中心にそ

@Isao 18:22
なりますね。ちろん、自動テストを書く、設計すること自体もそうですし、さっきそのクーボネですね。テスト環境を構築するっていうところも含めて、サポートしています。

@potato4d 18:33
なかなか、現場のメンバーだけだと、こうやるのも大変で、手が回らないっていう方も多いんで、そういうのをやってくださる人がいるのは、すごい楽しいですね。

@Isao 18:44
こう、信頼性の高いテスト環境を提供するところまでが、やっぱ結構ハードルが高いので、1回うまく走り出すと、しばらくは大丈夫そうで、テスト増やしていっても、そこに持っていくまでが大変でま。そういう意味でも、stっていう10人のロールが社内にあるっていうのもある。

@potato4d 19:03
ありがとうございます、そうですね、はじめのやっぱ構築が構築プラス、うまくワークする状態に持っていくっていうのは、やっぱり昔も今も大変っていうのは、はいは変わらないんですね。

@Isao 19:15
そうなんですよね、そこをやっぱり行動書いてるエンジニア自身がやると、やっぱその人のモチベーションとかろしちゃったりして、だんだんちょっと優先度下がっていって、そう捨てられちゃうっていう残念なことに

@potato4d 19:27
なるっていうのは、やっぱ

@potato4d 19:32
モチベーションだけじゃなく、やっぱプロジェクトが忙しくなったから、今はできないとかもやっぱ出てきちゃいますもんね、だんだん

@Isao 19:38
はいあるんですけど、でも、やるんだったら、早めにやった方がいいっていうとこが。でも、そうですね。

@potato4d 19:45
なるほど、あ、ありがとうございます。はい、今結構もう色々最新事情を聞いていく中で、それぞれのこうこういったツールが使えてみたいな。聞けたんで、まあ、せっかくなんで一緒にそういった環境を作り出している最新のツールとか気になる。今勇さんの方で気になっているな。確信的言ったら、大さかもしれないんですけど、いいなと思ってるツールとかあったら、なんかそういう話もちょっと聞きたいなと思うんですけど、なんかこう

4. 気になるツールや最新事情 19:49

@potato4d 20:11
今のこうか、賢いイベイトをしてくれるであったりま賢いセレクター持っているみたいなこう、かなり現代的なツールっていうところで、今だとフロントエンドとして、ファーストチョイスにあげるとしたら、勇さんの方でこういうものじゃないかなとかって思ってるのってあったりします。

@Isao 20:28
そうですね、ファーストプライス初めて使うっていうんだったら、クレイライトおすすめしますね。フレイアウトや、それはラッパーもあるんですけど、もま、単純にとっかかりとして、すごくいいと思っています。で、テストのプラットホームというか、このレポーティングとかも含めたプルとしては、サイプレス。あが

@Isao 20:52
としてはすごくいいと思うんですけど、サイプレス少し癖があってですね。テストリップがサイプレスのウィンドウが開いて、その中でアフレームでテスト対象を描画して操作する。はいになってるので、結構別のタブを開いたり、ウインドを開いたり、みたいなものとかに対応してなかったりするのがちょっとすぐ使いづらいなって思う

@Isao 21:12
ま。サービスによりけりですウェブサービスによりけりですけども、おところがあるので、そういうところの引っかかりがラートだと比較的少ないのかなっていうのと、これcrom限定なんですけども、エクステンションを読み込めるんですね。おお、テストプラウが立ち上げるときに、

@Isao 21:30
はい、エクステンション前提のテストっていうのも、実行することができます。で、アルトキャリアの方だと、多分アペピアとか触ったことある方もいらっしゃると思うんですけど、ま、ちょっと個人的な見解を含むんですけど。はい、コンセプトとしては、ブラウザ操作に特化している形で、プレイライトはただテスト

@Isao 21:49
振るっていうのを主材に置かれているので、さっきのセレクターとかもそうなんですけど、もま、アサーションとかは、ゲストによくあるオーセンティケーションの問題ですね。毎回ログインするのかっていう話とかあると思うんですけど、はい、ケットケースする時にていうところとかも、オセンケンのキャッシュを使って、高速にゲストリ行したりとかっていうところもサポートがあるので、テストツールっていう意味でも、すごくえ行れてるツールだと思ってます。

@potato4d 22:16
であれば、まあ、なんか今ブジェストが入っているから、そこにパペティa突っ込もうみたいなことをするよりは、ま、素直にプレイライトとか使う方が。

@Isao 22:27
はい、そこまでそんなにそのデストのこの機能をすごく使いたいんだ、みたいなものがあれば別ですけど、もま、最初はプレイヤート1本で使ってみて、ちょっともうちょっとその拡張的なことというか、やっていく中で、ユニットテストで突きかったジェストのナとかを使いたいときに、少しまた検討するっていうのがいいと思います。

@potato4d 22:46
なるほど、なるほど、ちょっと私、サイプレスしか使ったことがなかったので、ちょっとプレイライトを触ってみようとは思います。

@Isao 22:53
さくっと、最初のテストケースが作れるっていうのは、すごく思ってます。

@potato4d 22:58
プレイライトって、microsoftの開発のやつでしたっけ。

@Isao 23:01
そうですね、

@potato4d 23:04
じゃ、かなりツール自体の信頼性もまある

@Isao 23:06
の高いそうですね。継続的に、メンテナンスというか、タ開発が行われてます。

@potato4d 23:14
じゃあ、まあ、ファーストチュースとしては、例外とかあ、

@potato4d 23:17
おすすめ。はい、

@Isao 23:18
おすすめでしたね。さっき言ったそのリアクトやビーのセレ、あの、そのフレダルトにエクスペリメンタルが入ってるの。あっとま遊びでしてみるのもいいと思います。

@potato4d 23:28
いいですね、ちょっと私も試してみようかなと思います、ありがとうございます

@Isao 23:34
はい、

5. 正直ベースで語りたい QA との関係 23:36

@potato4d 23:36
ではですね、本日もう1つ語りたいテーマが実はあってですね。これ最後に持ってきたんですけど、結構正直ベースで語りたい話として、あの、結構イツテストを導入するにあたって、1番難しいところとして、そのうちの会社とかもそうですし、多分これを聞いてくださっている方にも、該当するような会社も多いかなと思うんですけど、あの、急営テストがしっかりされている会社の場合、こうイ2eを書いても、別にキエがなくなるわけじゃないから、こうどうなんだろうみたいな反応されることとかって、正直こう。

@potato4d 24:09
社内のプロジェクトとかでいっぱいあると思っていて、なんかこう開発の生産性を担保するだけだったら、ユニットテストでいいんじゃない。でも、別にeテスト書いたところで、qaがなくなるわけじゃないから、こうそんなに効率的じゃないよね。とか、なんかま。これはメンテナンスコストへのその印象とか、偏見とかはやっぱり多分に含まれてるかなとは思うんですけど、なんかそういう点でこうqaの肩代わりになるかどうかみたいなのすごくいいを書く上で、あの

@potato4d 24:35
話題になりがちかなと思っていて、なんかいさん的にそのqaとeの関係みたいなのって、正直どういうふうに積み上げていくといいとか、どういう風にやっていくと、うまくこうワークするんだろうみたいなのってえ、考えていることとかってありますかね。あるいは、こう開発者に向けて、その別に救援をやった上で、いつを書いてもいいんだよっていう説得でもいいかなとは思うんですけど、なんかこう

@potato4d 24:59
自分の中での考えとかがあったら聞きたいなと思っております。はい、

@Isao 25:03
そういう意味でいくと、qaを置き換えるための自動テストというと、コストを抑えるための自動テストっていうのは、成功事例を僕はもうほぼ聞いたことがないですね。

@Isao 25:17
あまりうまくいかないですね、やっぱりコストは高すぎるのと、旧霊テストっていうやっぱ、人がやることを前提としたテストの設計だったり、観点だったりするので、それを機械化する単純に機械化しようとすると、すごくこれよりコストも上がってしまうっていうのもあって、なかなかうまく置き換えられないことは

@Isao 25:38
これかなと思ってます。それでもなお、僕はあの開発者自身がこのイェストを書くっていうところに意味があると思っていて。はい、それはいくつか理由があるんですけども、旧営のそのま、主動テストっていうところの品質担当っていう部分はあったとしても、それにプラスして、自動テストをこれは可能であれば、より早い段階で早い段階っていうのは、開発段階、コルレビの段階で自動テスト

@Isao 26:06
ええ

@Isao 26:08
1テストをえ、実行できるという状態になれば、ここ開発スピードのえ、高速化にななると思いますし、あとはこれユニットテストの例がいいと思うんですけど、ユニットテストを前提とした行動はま、比較的綺麗にかけると思うんですね。はい、あのプロダクションコード、それと同じように自動テストの書きやすいような。

@Isao 26:28
プロダクションコードっていうか、まあromであったりだとか、アクションとかとかっていうのもあると思っていて、そういった面でのえ、テストを意識するテストを前提にしたえ、コード作りっていう風にすると、メンテナンス性も上がりますし、自動テストのえ、メンテナンスも結構やりやすくなる。

@Isao 26:49
もちろん、そこにはあの、その自動テストを書くためのえ、スキルとか点検みたいなものが必要なので、一応奇跡にすごくいい。その自動テストのコードがかけたりするわけではないので、ちょっとここは長い目で見る必要があるかなとは思っています。setチームでは、チーム内で作っているプロダクトもあるんですけども、そのプロダクトは、フルリクエストをえー作った時に、

@Isao 27:18
フロントエンドのイツテストも走るようになってて、プロダクションコード書いて、etテストも書いて、デビュー依頼するみたいな形になってるプロダクトがあるんですけども、こういうものをデビューする側の観点からすると、もうすでにこのテストは通過してるから大丈夫だよねっていうその安心感のも、はい、全体を見たデビューができたりするので、

@Isao 27:38
結構そのバグ探しのためのデビューをする必要があ

@potato4d 27:42
あですね。なるほど、なるほど、

@Isao 27:44
なんでもっとその別のところアリダビリティだったり、ちょっとそのここシンプルできないとかはいっていうところに注力できるし、だから、その遠慮が入れなくなるっていうんです。これだと個人的な感覚もあるんですけど、も、はい、ものすごい複雑なロジックが書かれてるとして、ちょっとこれ。こういう風にリファクタリングして、見ないみたいな提案をするときに、そこに、もちろんユニットテストがあると、それだけでうまく回ると思いますし。ただ、そこがユニットテストにスコープに収まらないような

@Isao 28:10
規模の変更になったりすると、そこで一テストがあると、結構大きなコード変更しても、そのまま動くのが確認できるというところは、結構そこはまユニットテストで得られる安心感とま、似たような形の安心感っていうのはあるかなと思っています。ただ、そのためには、そのヘッドアップがヘッドアップっていうのは、その利動テストの環境が難しいので、そこだけは

@Isao 28:33
未だに。なんかその銀の弾丸はない状態ですね。これやっとけばいいみたいなものはなくて、そのプロダクトの規模であったりだとか、あとは、その依存関係の多さとか、複雑さとかっていうものに依存する形にはなるかなと思っています。

@potato4d 28:52
かいです

@potato4d 28:53
じゃあ、やっぱりこう変に置き換え用であったり、変にこれをやる分の個をどっかで削減しようっていうよりはま、結果的に、例えばそのコードエレビュー、本質的な部分にフォカフォーカスできたりであったりとか。まあ、結果的に品質が高まることによってこうプロダクトにとって、プラスになるであったりとかっていうところをこう意識しながらやっていく方がま成功しやすいというか、まあ、圧倒的に良い方向に良い成果につながるかなっていうところ、

@potato4d 29:21
そうですかね。

@Isao 29:23
はい、そうでいくと、コストを減らす方向ではなくて、自動テストを作るっていう投資をもう逆に追加する感じの感覚がいいですね。投資することで、スピードや品質っていうのを得られるように動くっていうのは、1つまま自動テストが成功するパターンとしてはあると思っています。

@potato4d 29:41
じゃ、まあ、今現状でポストをかける代わりにこうコードベースがよりスケールした時に増えていく行動を記述したりだとか、レビューするコストっていうのを、上昇を緩やかにするための投資ぐらいで運用していくのがベスト

@Isao 29:54
ですかね。そうですね、だから、今もこんなにコストかける必要があるのかって思う時は結構あるかもしれないな。なるほど、ただゆくゆくあ、やっといてよかったっていうは、サービスが大きくなるにつれて感じることは多くない。

@potato4d 30:09
じゃあ、その精神をこう忘れずにやっていくのが1番大切ですかね。

@Isao 30:16
ま、その中でも、やっぱりその長く続けて、やっとその目が出るような成果みたいな形になると続けるのが難しいと思うので、

@Isao 30:27
そういう意味でも、最初から急へ置き換えようっていう大きな目標を掲げるよりも、ちょっとずつ足元から少しちょっと楽をしてみようっていうもので、例えば、モークテストとかまデプロした後に、軽く手で今労作確認しているとかが、もしあれば、それを自動化していいる。で、それがうまくいったら、ちょっと手を広げて、もうちょっとたくさんのテストケース。普段だったら、テロイドの中道確認ではま、時間もないし、テストの

@Isao 30:55
データのセットアップも大変だから、やってない。救援にお願いしてるっていうようなものも、広げていくっていう選択肢が出てくると思。

@potato4d 31:04
確かに、スモークテストのレイヤーとして、1個設けるっていうのは、なんか考え方として良さそうな気が

@potato4d 31:10
しますね。はい、

@Isao 31:11
あと、結構幅も狭い

@potato4d 31:13
そうですね。そうすね、はい、じゃあまあこういきなりこう大それたことをこうしようとはせずに、やっぱ着実にやっていくのが大切ですね。

@potato4d 31:25
やっぱりこいついってなると、コストもかかるし、その分、何かの成果をみたいな風にやっぱいちゃいがちなところはあるかなと思うんですけど、

@Isao 31:32
あ、はい、それも求められると思うんですよね。自動テストにたしたんだったら、9営期間とか、人数テストの人数減らせるよね。みたいな感じのああると思うんですけども、そこじゃないんだって言っていく。

@Isao 31:51
それがそうですね、だから、もしおすごい大きなモノリシックなアキテクチャーのアプリケーションを、いきなり全部、その多分、100個も200個もある。マイクロサービスで、いきなり変えようとする人。多分あんまりいないと思うん

@potato4d 32:03
ん、ま、そうですね、

@Isao 32:04
少しずつ切り出していくと思うんですよね、やるとしてもそうですね、やるんだったら、そういう感覚が機械ですね。少しね、少しずつ

@potato4d 32:13
じゃあまあこう変にこう全ての願望を乗せすぎずに

@potato4d 32:19
まやっていきましょう。っていうのが1番大切

@Isao 32:24
はい、自動テスト書き慣れてる人でもいきなり大。それたことをするのは難しいので、移動テストの勉強がったら、ちょっとやってみようっていう感覚ですね。うん、うん、

@potato4d 32:35
ちゃんと

@potato4d 32:36
心に刻んでおこうと、

@potato4d 32:39
やっぱりやらなければやらないほど、期待値上がっちゃうっていうのが正直とかってあるなと思うんで。

@Isao 32:47
そうか、

@potato4d 32:48
ちょっとシクに

@Isao 32:50
qaによる手動テストのお手本みたいなのがあるから、なんか、そこに近づけなきゃそうなんあると思うんですよね。それよりも、そのデベロッパーが自動テストを書くんであれば、そのユニットテストからの延長線上って考える方がちょっと素直なんですね。そうすると、やっぱま自然にユニットテストは基本的にえたくさん書いてでエド、自然トテストはちょっとだけ書く。はいはいはい、

@Isao 33:18
エトのテストなんかたくさん書かないとカバーできないなって思ったら、ちょっと振り返ってみて。これ、ユニットテストで担保すればいいんじゃない。もっと小さいおコネントとか単位でテストすればいいんじゃないの。みたいな話できる。あ、

@potato4d 33:30
あの、このコードベース自体の問題に、

@potato4d 33:33
はい

@Isao 33:33
はいもっていくから、だんだんその広い範囲のテストを小さい範囲のテストにえ落としていくってことも、やりやすい。結果的に、全体的に、そのバランスの取れたリドテスト構成ってのが、作り上げられるふうになっていると思います。

@potato4d 33:50
それはすごいこういい考え方か、なんかうまく和服しそうなイメージ。そう

@Isao 33:57
ですね、それをやっぱり自分たちで、それを別の旧営エンジニアとかと協力もちろんする必要もあると思っているんですけど、も。ただ、それほどフロントエアだけではなくてもいいと思うんですけども、みんなで動テスト書いていくっていうあ、みんなでっていうの、ここで言うとチームとかですね。うん、出ていくって形になると、そこのどのフェイズでどのレベルのものを担保しようかって話にもなって、

@Isao 34:22
これは結果的に全体的にその手動テストも含めたテストのバランスを考えることにつながると思うので、そこまで行くと結果的に認識も上がるし、 9エの構想も減るし、え、リスのスピードも上がるっていうとこまで持っていけるけるんじゃないかなって。

@potato4d 34:37
いや、なんかこう。私、今回の収録でなかなかこう言い続き、テストとについてこううまくワークするイメージが持てない部分もあって、せっかくなんで聞いてみようって言って、はい、主に臨んだんですけど、なんかかなりイメージしやすくなって、

@potato4d 34:57
もし聞いてる皆さんにも参考になれば、

@potato4d 34:59
はい、

@Isao 35:00
もしもしくはいや、そうは言ってもって思うことがあれば、ぜひも含めて、僕もまだ全ての辞書を把握できるわけじゃないんで、そういう色んなパターンが多分あると思うので、そういう意味では、ユニットテストよりも、やっぱ広い範囲あ、広い範囲ってない。イベロッパーだけじゃなくて、え、pdmはqaとかデザイナーとかも巻き込んだ形になるので、結構戦略的に動く必要が出てくる

@Isao 35:26
はあると思っていて、そこは難しいんですけど、もまとりあえず難しいけど、そこを抜きにしてはうまく進められないなっていうところを心に留めておくだけでも結構違うと思うので、そこは意識があって

@potato4d 35:40
いいと思いそうですね。なかなかこう成功談も失敗談もたくさん生まれそうな話はありますけど、もし言ってる人の中でいつやってこうだってよ。みたいなのがあったら、せっかくなんでこう。ツイートとかで反論欲しいところでは

@Isao 35:53
はいます。結構引っぱい両方きたいです。

@potato4d 35:57
かなり色々聞いていきましたけど、いざおさんえ、ほんとに話ありがとうございました。

@Isao 36:03
あ、いえ、こちらこそ、お招きいただきありがとうございます。

6. クロージング 36:08

@potato4d 36:09
というわけでですねえ、今回はいおさんを招待してですねエンドエンドテストのえ、現状についてお話しいただきました。ラインのフロントエンド組織え、UITではま、このようなフロントエンドに関するえ、議論やえ、ディスカッションを日で行っております。これまで、UITeサイトで公開したエピソードの中には、社内の勉強会や法会などなどから生まれた自宅等々もたくさんありますので、今後発信していければなと思います。

@potato4d 36:36
また、今回みたいにえ、UIT以外の人を招待して、フロントエンドにか関する4アについても、話していければなと思っております。おえ、ポートキャストのエピソードを聞いてですねえ、何か感想、ボイキング、まそうなどなどありましたらですね。ハッシュタグシャープ、UIT、アンダースコアインサイド見てつぶれていただければと思います。今回色々いいテストについて話していったんで、まあ、成功だ。失敗談とか行けるといいかなと思っております。

@potato4d 37:02
またえ、この話を聞いてですね。ラインに興味を持ってくださった方は、え、この小のとサ花部の方に求人へのインクを貼っております。まだですねえ、ズomを利用してのオンラインでのカル面談を受け付けておりますので。え、もし興味あればえ、気軽にご連絡いただければと思います。今回はせっかくですので、え、UITに加えて、setの方のえ、jdも来ておこうかなと思うので、もし、setに興味があれば、気軽にそちらにご連絡いただければと思います。

@Isao 37:30
はい、ぜひぜひ

@potato4d 37:32
お願いします。というわけでえ、今回はイツテスについて語っていていきました。えいささん本日はありがとうございました、

@Isao 37:40
ありがとうございました。