00:05
はい、みなさんこんばんは。株式会社ゆめみでチャレンジ取り締役をしておりますキースことくわはらです。
Web 業界のなんでも雑談室でようこそ。この番組ではWeb 業界に関することや、様々な雑談などの情報を発信していきたいと思います。
6月3日、今日ですけども、実は私は勇気を取っておりましてですね。
先月、まず稼働が高かったので、体調をもうちょっとまだ回復したいと思ったし、ちょっと勉強したいものもあったので、
ちょっと今日は勇気を取らせていただいたって感じになります。
で、まあ、しっかり休み取ったんですけどね。なんか午前中ひたすら洗濯をしたりとか、洗い物をしたりとか、掃除をしたりとかで、
家事ばっかりしていて、午後から勉強を始めてたんですけど、本当に今日やると思ってた勉強とか、書こうと思ってた行動、他にもあったんですけど、今日はちょっと
ひょんなことからですね、E2Eテストフレームワークの勉強を実は始めてしまいましてですね。
始めてしまったが最後、まあ面白くてどんどんどんどん行動を書き倒してて、そんな1日だったんですけど。
で、今日学んだE2Eのテストフレームワークはですね、サイプレスというフレームワークになります。
結構前から生まれていて、確か2015年かなにコミュニティだったかリリースだったかされているフレームワークですね。
フロントエンド周りのテストフレームワークとしては結構有名なものになります。
他には、あとテストカフェとか、あと僕が結構好きだったんですけど、コードセプトジェスというものがあって、それと僕はパペティアというものを組み合わせるものが良かったなと思ったりしますけど。
ただ、実際のプロジェクトでそんなにE2Eテストを書いたことがあまりなくてですね、というのもE2Eまでいくと基本的に
お客さんのほうの受入テストで賄ってしまうとか、もしくは弊社は結構別の会社さんにテスト委託をしたりするので、こちらでそこまでのテストはしないとか、ユニットテストくらいまではやるとか、
単体テストと言われるものですけど、まではやったりしますけどね。ただそれでもテストコードを書くか書かないかというのは結構プロジェクトによってまちまちで、
実際にクライアントさんにもテストっていうところのテストコードの費用まで取ってしっかりやらせてくれって言っても、そこの費用は最終的にこちらでポチポチとあげたりするし、そこはいりません。
だからそこのお金を削って少しでも早くとか安くしてくださいみたいなことを言われることもあったりしますね。
なのでE2Eまでテストを書くことって実際の現場ではあんまりないんですよね。
なので良いのか悪いのかっていうのはまちまちですし、結果的にその不具合が結構起きたりとかデグレったりしますとか、
なんだかんだあるので、こちら側の目線で言うとやれるならやった方がいいよっていうふうには思いますし、
こちら側だとやりたいぐらいのスタンスではあるんですけど、なかなか実体としてはテストを書かせてもらえないっていうことが多かったりはします。
今回はあるプロジェクトでテストを書きたいなと思っていて、1回生納品をしたんですけども、
03:05
やっぱり手動でテスト項目書をバリバリ書いて、だいたいExcelで書くんですけど、
それを人でポチポチとあげて実行するっていうのはやっぱり効率が悪いというか、
項目書を書くこと自体は別にテストコードを書くことと対比になるものでそれは別にいいんですけど、
やっぱりテスト項目書を人の手でしかも日本語でボリボリ書いていくってなると、
語述であったりとか書き方とか表現の違いがもしかしたら人によって違ったり、もしくはそのテストする対象によって書き方が違ったりとかしますし、
やっぱり統一性が結構なくなったりすると思っているし、やっぱりヒューマンエラーが起きるわけですよね。
いくら一人の人が書いたとしてもだんだん疲れてきて書いてしまったりとか、
結構抜け漏れがあったりしたりとかしてあるので、
あんまりやっぱりテストを日本語でテスト項目書を書くよりはやっぱりコードで書きたいなというふうに僕も思いますし、
やっぱりコードで書くほうが全然楽しいんですよね。
なのでできればやりたいなと思っています。
よしんぼ、テスト項目書を書くほうが早くて、テストコードのほうが時間がかかったとしますし、
ただ書いた後に実行する速度はどう考えたってテストコードのほうが早いわけなんですよ。
その項目書、例えばあるプロジェクトで8000件ぐらいの、全てのテスト項目書のテストケースを合計すると8000件以上になりましたと、
それ実行するのにものすごい時間がかかってしまうとか、
1日どんだけ早くてもやっぱり2、300ケース、300とかいくことはほぼほぼないと思うんですけど、
いっても200ケースとすると、8000件するとだいたい1日8時間なので、
何時間ですか?ちょっとわからないですけど、ぐらいガンガンにかかるわけなんですよね。
とかなる中で、やっぱりテストコードだとやっぱり機械がガッと実行してくれるので、
正直どんだけかかったとしても1時間、2時間ぐらいで多分終わってくれるんですよね。
しかも人がやらなくて、機械がやるのでミスなくテストを実行してくれるし、
結果もスパッとまとめて出力をしてくれる。カバレッジって言われるもんですね。
出してくれるので、やっぱり僕はテストコードを書くほうがいいのかなと思います。
人間がテストするって、人間ってやっぱり不安定なものなので、人間自体がミスすることもあるじゃないですか。
チェックする人間自体もミスをするので、人のチェックをまた人がするのかみたいな話になって、
どんどんどんどん管理コストがかかってきたりするし、
ミスが起きる時のためのエラーハンドリングをまた人がするという人件費がどんどんかかっていくので、
僕はやっぱりテストを実行するっていうことに関しては絶対に機械のほうがいいと思っている。
そうなるとやはりテストコードを書きたいなって思ってますし、それでプロジェクトを進めたいなと正直思ってます。
そういう説明をしたときに、お客さんとしても理解してくれるお客さんもたまにはいるんですけど、
06:02
とはいえやっぱりお金と同期の話がどうしても出てくるんですよね。
本当にそれはしょうがないですね。ビジネスインパクトとか、お客さんとしては経営目標もありますし、
売上目標もあったりしますし、逆にその経費ここまでかけられないなっていうところもあったりするので、
しょうがないとは思いますね、そういうところは。
なので、長い目線見たときには結果的にお金かかってしまってるじゃんっていうことはよくあるんですけど、
そこまで説得ができなかったこちらの、説得力がないというふうに反省をしつつも、毎回毎回とか言って書かないこともあったりするんですけど。
こちらとしては逆にテストコードを書くという実績が少ないですし、知見がまだまだ溜まっていないというのもあるので、
テストコードを書くときにこれだけの見積もり、日数かかりますよっていうふうになってしまってるんですけど、
そこ知見が溜まったり鍛えられていくとそこのコースをどんどん削減できるというか、
もっと効率的にテスト書くことができるよみたいなふうに体制組めるようになっていれば、
こちらとしても提案が仕方もちょっと変わってくるし、お客さんへの金額のインパクトもなくなってくるんだろうなと思っているので、
できればこういうところはしっかりチャレンジして知見をどんどん溜めていって、お互いに時間もかけずにお金もかけずに、
あといって品数も高くしていくっていうふうに持っていけたらいいなと思っていたりはしています。
その一つとして今日はそのE2Eテストの勉強をしてみたという感じですね。
僕が書くかっていうよりも本当は現場のメンバーが書いてくれたほうが本当は嬉しかったりしますし、
現場のメンバーにもそのテストっていうところの重要性とか知見っていうのをどんどん溜めていきたいなと正直思っていて、
何度か弊社でもそういうことをやろうっていうふうに企画した人もいるんですけど、なかなか定着しなかったんですけど、
最近は結構いろんなプロジェクトでしっかりテスト書くっていう文化が根付いているらしいので、
もう少し加速して、イメミとしてもテストの知見というよりも舞台というか基礎力というところを上げて、
イメミってイメミさんに頼むとやはり品質が高く早くプロダクトを作ってくれるよっていうふうに思われるように頑張っていきたいなと思っていたりします。
なかなかビジネスインパクトを技術者目線でなかなかアクションを起こすというのは難しいところがあってなかなか貢献しづらいところがあるんですけど、
そうやって日々僕らもビジネスコードを考えてコードを書いてますよっていうのを訴えていきたいなと思ったりはしていますね。
なんか長々と語ってしまいましたが、今日はそんな感じでツイーテースの話をしたいなと思いました。
本当はサイプレスの話が結構したかったんですけど、気づいたらビジネスの話になってしまいましたけど、
サイプレス時代のコードの話とかはいろんなところでいろんな人が記事を書いてますのでそちらを見ていただければと思いますが、
ただ思ったのはコードの書きやすさとかその辺はすごく良かったですね。
とにかくテストコードを1回でもユニットテストを書いたことある人だと親和性があると思いますし、
こうやって書くんだよねみたいなコンフィギュアを設定して、あとはこの辺にスペックみたいなファイルを作って、
あとはコマンド実行したらテストが流れてくれるんだみたいな感じのいつもの流れなんですけど、それに則っているので。
09:05
スタートして学習コストがそんなに軽かったりそんなことはなかったですし、
僕も今日学びながらすぐにパッと書けるようになったので結構良かったなと思います。
でも他のテストフレームワークを見た感じでいくと結構書き方が似てきてるんですよね。
どのテストE2Eであろうとユニットテストだろうと書き方が似てます。
なので結構書きっぷりっていうところに差は出てこなくなっているので、それ以外のところですね、
環境、周辺のところとか細かいところ、痒いところに手が届くような機能があるとか、
デバッグしやすさとかアバレッジが結構美しく出てるとかみたいなそういういろんなことを含めてE2Eのテストフレームワークとか選ぶというのかなと思います。
僕結構ちょっと前に使ってたコードセプトジェスというのは何が良かったかというと、
一つ一つのテストのアターションの書き方とか、実行の速度とかステップの書き方ですけど、
その書き方がものすごく英文なんですよね。
例えばこのページにアクセスしてくださいっていうのをフレームワークに命令させるときは、
i.amonpageっていうふうに書くんですね。
iっていうのがインスタンスオブジェクトで、その中のamonpageっていうメソッド名があるんですけど、
そのメソッド名を書いて、その中の引数にアクセスしたURLを書きますと。
そしたらそのページにアクセスしてくれっていう感じなので、
ほんと英文で書くような感じがするので、
一個一個の何をやりますかっていうのがすごく明確でわかりやすいんですよね。
例えば入力フォーム、インプット、タイプテキストのところとかにフォーカスがあったときに、
こういう文言を入れてくださいって言ったら、
i.fillfieldでキーの名前と実際のバリューを設定するみたいな感じで、
ほんとわかりやすいんですね。
ボタンクリックのところもボタンにフォーカスがあったらi.clickでボタンの名前もしくは取得したオブジェクトみたいなのを引数に渡すという感じで、
めちゃくちゃ書きやすいんで、
もし興味があったらCodeCept.jsを見ていただきたいと思いますけど、
でもこれを使って、
あと今日Cypressを使ってみたんですけど、
やっぱCypressはいいんじゃねえかっていうぐらいにも書きやすかったし、
環境周りも整っていて、
やっぱり時間がかけられて作られたプレイワークだなと思いますけども、
とても良かったので、
特に実行中のストップの仕方とかもそうですし、
ブラウザの表現とか、
やっぱり美しく表現してくれるのがめちゃくちゃ嬉しくてですね、
勝手にスクリーンショットも撮ってくれるし、
実行途中のテストのどのように流れているかという動画も撮ってくれるんですよね。
なのですごく目でパッと見てもわかりやすいので、
とても良かったですね。
まあそんないろんなところ、
なんかこういうところあったらいいなみたいなのをCypressは結構用意してくれるので、
やっぱりこのフレームワークだというので、
お勧めしておきます。
12:00
どちらも良かったですね、CodeCeptも良かったし、
テストカフェはテストカフェでもかなり良くてですね、
各ブラウザテストのところを勝手にやってくれるというところがあって、
設定もそんなにかかなくても自動でバンバンやってくれるという幅広さは本当に良かったと思いますね。
あと対応ブラウザの種類も多かったので、
テストカフェはテストカフェで結構充実していいと思いますけどね。
まあその辺は好みと思うので、
皆さんの方でいろいろ触ってみて、
実行していってみたらいいんじゃないかなと思います。
まあ今ですね、今日僕がCypressを学んだ感じで、
僕はこれから当分は多分Cypress推しになると思います。
そんな感じですかね。
ちょっと技術的な話まで突っ込むと、
もう30分ぐらい延々と語れるんですけど、
ちょっともう12分も喋ってね、
今回はこれでストップしようと思いますが、
はい、いい感じで今日はテストフレーバーの話をしました。
来週とか次回はですね、
そのテストそのものの信頼性とか変質について
ちょっと喋りたいなと思っていることがあるので、
その辺をまた次回喋りたいなと思っておりますので、
もし興味があれば聞いていただければなと思います。
はい、ではこんなところで今日は終わりにしたいと思います。
はい、また何か聞きたいこと、話して欲しいことがありましたら、
いつでもレターをお待ちしておりますので、
お気軽に投げていただければなと思います。
ではまた次回の収録でお会いしましょう。
バイバイ。
