00:05
はい、みなさんこんにちは。KEITHこと桑原です。本日もやっていきましょう。KEITHのエンジニア雑談チャンネルです。
この番組では、ウェブ業界に関することやエンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
今日はですね、話すネタ2つあって、1つは僕、読書の記録的なものをいくつか使ってて、
読書メモとしてノーションにテキストを書いたりとか、BOOKLOGというサービスを使ってますね。
これは自分の本棚みたいなのをオンラインで作れて、それをシェアしたりとか、そこに自分の感想とかメモを残しておきたいとか、
そんなことができたりするサービスですね。こちらも一応使ってはいて、そのBOOKLOGさんが最近出しているテーマとして、
2024年読みたい本、みたいなキャンペーン的なものをやってたんですね。
別にキャンペーンと言って何かインセンティブをもらえるわけではないですけど、企画ですね。
正式募集は、2024年1月特別企画、2024年私が読みたい本3000円というところで、このテーマでブックリストを作っておきましょう。
一応この抽選で10名様に選んだ本のうち1冊をプレゼントしてくれるというので、まだ読んでない本を選べってことですね。
独領した本は確かに読みたいではないですから、選べっていうので、ここから3冊選んで、
それについてだらだら喋るのも1つかなと思ったんですけど、そこではないところで、
今日はタイトルにありますリアクトテスティングライブラリーのガイディングプリンシプルを眺めながらって書いてあるところですね。
ここに書いてあるすごい短いページなんですけど、Get Startedの中にプリンシプルが書いてあったので、その思想的なところが読めるなら読んでみようと。
昨日読んだんですけど、わりと共感が強かったんですよね。
僕はテスティングライブラリー一度も触ったことがなくて、大体テスト書くときは今まで語った通りですけど、
僕スタートはAバーから入ったのかな?そんなわけないな。歴史的にAバーはもうちょっと後から生まれてるはずなので、
多分一番最初のテストは本当にPHPユニットから入った気がしますね。
あの辺から入って、Jユニット一瞬触ってないかな?みたいなところですね。
PHPの頃に単体テストのコード書き始めたっていうのがあって、
PHPユニット触って、夢見に来て最初に触ったのがAバーだった気がしますが、
OSSで自分個人でやってきたのがあって、多分MOCAから入ったのかな?
JSのテスト書くことがほとんどで、JS以外のテストは多分PHPユニットしか書いたことない気がしますが、
大体テストは僕インテグレーションテストとかあんま書いたことなく、E2Eもほぼ書いてないです。
基本的にはユニットテストばっかり書いてるんですけど、
JSのテスティングフレームワークとして最古産と言っていいでしょう。MOCAから入ったと思います。
MOCAプラスチャイかな?でやったり、JASMINEやったり、
なんか他にもあった気がしますけど全然思い出せない。
あとはAVAですね。AVAでAVA。みんなAVAって読んでましたけど、新しい発音がAVAらしいですね。
あれも確かメンテナンスされなくなった気がするんで、もうほぼ使ってないので。
03:02
そっからJESTに移って、今はほぼほぼJESTばっかり書いてますけど、
最近開発環境としてBEATを使うことがほぼほぼになってきたので、
BEATと言えばテスティングライブラリーがB-TESTっていうのがあるんですよ。
B-TESTの読み方合ってるかちょっとまだ調べてないです。
本当はBY-TESTとかわかんないですけど、本体の読み方がBEATだからB-TESTで合ってるでしょうと思いますが、
JESTとかB-TESTとかその辺ですね。最近モダンなフレームワークばっかり触ってて、
REACT用のテスティングライブラリー、REACTテスティングライブラリーですね。
っていうものを触ったことがなくて、案件で使っている案件があって、
そのコードレビューするとき全然触ったことがないので、
公式ドキュメント見ながらレビューしなきゃいけなく、
そうすると時間が遅かったので、一回ちゃんと触ってみようというので、
一回ドキュメントを見始めたんですよね。
その時にこのガイディングプリンシップが見えたので、それを読んでいこうと。
前置きすごい長くなりましたけど、じゃあ早速入っていきたいんですけど、
冒頭の一言がかなり当たり前のことなんですけど、ちゃんと言語化されるのがいいなと思って、
ツイートで投稿されたものを単純に引用されてるだけですけど、
ケントシー・ドッツさんという方がおっしゃっていた一言。
英語で書かれてるんですけど、
The more your tests resemble the way your software is used,
the more confidence that they can give youと言ってますね。
ソフトウェアの使用方法とテストってものが似てくれば似てくるほど、
その信頼性ってのも高まりますよねっていうふうにおっしゃってます。
当たり前っちゃ当たり前なんですけど、ちゃんと言われるとそりゃそうだよね。
この一言に尽きるっていうのがおっしゃってます。
そこから先はもうちょっと書いてあって、いろんなことが。
テスティングライブラリーのチームの方々は、
ウェブページの使われ方に近いテストを書くことを推奨する
メソッドとかユーティリティだけをなるべく公開するようにしてます。
この一言も結構よくて、テストってすごく大事ではあるんですけど、
本体が使われることを想定したテストが書かれるようなもの、
それを推奨するだけを公開するっていう思想が本当によくて、
つまりはReactテスティングライブラリーっていうのは
あるところ軽量でシンプルで理解しやすいっていうところを目指しているって話ですね。
これがまた僕はすごい好きで、
軽量だから正義ってわけではないですけども、
ある意味捨てやすいっていう思想が僕は大好きで。
それはなぜかというと依存度が下がるからですよね。
他の大体も可能であったりとか、
とはいえこのライブラリーを使ったコードとか、いわゆるカスタムコードですけど、
これが他でも利用できたりするっていうのはすごく良い話ではある。
エンジニアなので技術を使うんですけど、
技術に依存した仕事をしたいわけではないので。
なので軽量でシンプルっていうのはすごく良い。
あとは人の時間を奪わないで書ける。
つまり理解のしやすさですよね。
っていうところもすごく素晴らしいなと思って。
入門とか導入のコストとか離脱のコストが上がるっていうのは良い話ではあるんですけど、
とはいえコードの書き方っていうのは逆に言うと柔軟性が高いってことはカオスになりがちっていうのもあるので、
そのライブラリーの縛りがどこまであるかっていうのは結構トレードフではありますよ。
実際書き始めた後、凝ったものを書いたりとかがっつり使い始めた時の人のコストをかからないようにするって意味だと、
06:02
ちゃんとフレームワークの方が良かったりはします。
割と縛りのあるフレームワークは導入は厳しいですけど、
皆さん同じようなコードを必ず書くので、
そういう意味だと誰が書いても同じコードになるっていうのはすごい強みでもあるし、
コードレビューもしやすいですよね。
だいたいこうやって書くでしょ、皆さん。
最初から分かった上でコードをレビューするので、それも早いってのはある。
トレードフだと思いますけど、
問題はエンジニアの性格上、最初のペインをみんな取りたくないよねっていうのは正直あるので、
それなら他のライブラリ使うわっていうのはあるかもしれないので、
ちょっと視点が変わる可能性はありますけど、
まあまあさておき、テスティングライブラリっていうのはとにかく軽量シンプル、
理解しやすさっていうところを目指しているっていうのが結論でおたらてます。
これが本当にいいなと思いました。
あとですね、そっからユーティリティってところに関して、
3点指針に基づいたものが書かれてますけど、
そのうちの2つ目3つ目はちょっと長くなるしあれなんですけど、
1点目がもう本当にその通りだと思って、これが喋りたかったんですけど、
コンポーネントのレンダリングに関連するものであれば、
コンポーネントのインスタンスではなくDOMノードを扱い、
コンポーネントのインスタンスを扱うことは推奨しない。
いやこれなんですよね。
結局JSのテストって、結局DOMを扱うし、DOMに関するテストをすることがほとんどなんですけど、
もちろんそのユーティリティとかヘルパー関数とか切ったもの、
いわゆる関数モジュールのものはもちろん絶対やってほしいと思いますけど、
それはもうDOMでもコンポーネントの話でもないので、
今対象ののはコンポーネントのテスト。
もちろんリアクトディスティングライブラリーも名前の通りリアクトがついてるので、
リアクトのコンポーネントを仮想的にレンダリングして、
そのレンダリングされた結果のDOMですね、
裏で持っているDOMに関してテストをかけていくっていう思想ではあるんですけど、
あくまでDOMを使ってるってわけでコンポーネントのインスタンスを持つことは推奨しないし、
2番に置かれてますけどコンポーネントインスタンスを扱うことですね、
それの操作自体も推奨しないと。
結果的に言うとストーリーブックのテストに近い気がしますね。
スナップショットですと的なことを多分裏でやってるんじゃないかと思ってます。
僕がソースコード読んでないから分からないですけど、
とはいえレンダリングして裏で、
仮想DOMなのかなどうなんでしょうねっていうようなものを裏で持ってて、
それに関してのスナップショット的なことをやられてるとは思うんですけど、
それって最終的にはDOMを扱うことに変わりはないよね。
ブラウザーとしてもリアクトコンポーネントを受け取るわけではなく、
ブラウザーはあくまでそれを計算処理されて最終的にビルドされたDOMを扱うので、
本当に現実に近いものをテストするっていう思想としては
DOMロードを扱うというのは正しい話ですね。
なのでなるべくインスタンスを扱ったり、
そこで操作することはあまり推奨しないっていうのはすごくその通りだなっていうのはあります。
っていうのをちゃんとテスティングライブラリを提供している側の方も意識をして書かれていますよと。
それをちゃんとドキュメントでも書いて表明をしているっていうのはすごくいい話。
はい、というところで。
まあでもそのためにライブラリが提供するユーティリティとかAPIとかっていうのは
シンプルさっていうのはしっかり保っておきたいし、
かといって簡素になっちゃダメですよね。
シンプルと簡素っていうのは別物なので、あくまでシンプルにしたい。
09:00
で、シンプルであればあるほど柔軟さっていうのはセットにくっついてくるので、
柔軟さも乗っけるっていうのを読んで、
割とテスティングライブラリの僕に印象がかなり変わったので、
今後触ってみようと思うんですけど、
書きやすいっていう恩恵を得られる気がしてますね。
実際書いてみて現実ではいろんなケースがあると思います。
ライブラリの提供ってOSSやったら分かるんですけど、
ユーザーがどういう風に使ったり、
どんなケースで自分たちのライブラリを導入するのかっていうのは
もう想像できないんですよね。
なので最高なライブラリは存在しないっていうのはそういうところにあるんですけど。
とはいえテストってある程度形式ができたりするし、
最近はAIにテスト書かす方がやっぱり早いしクオリティも高いっていうので、
割とフォーマッティングができてるはずなんですよね。
そういう意味だとどのテスティングフレームワークを使っても
そんな大差はないって可能性はありますけど、
でも最終的に何を根拠にするかっていうと
多分思想にたどり着くと思ってて、
こういう思想で作っているよっていうのはすごく
共感があるものを使うのが僕はいいんじゃないかなと思ったりはします。
まあライブ抽象度高いお話になりますけど、
最終的にはエンジニアはそこにたどり着くんじゃないかなと思いますね。
技術の差っていうのはどうせコモディティ化した結果
なくなってくると思うんですよ。
差分なんてほぼないと思う。
あと書き方とAPIの若干の違いぐらいでしょ。
それは別にプロジェクトとしては大差ない話なので、
じゃあ最終的にエンジニアが好きなものを使えってことになる。
ってなると思想の話にたどり着くと思ってるので、
こういうのを表明されてるの嬉しいしいいなと思って
今日はそういう話をしてみました。
特にオチとかまとまりはないんですけど、
参考になれば幸いです。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の収録でお会いしましょう。
バイバイ。
