今日学んだこと適当に
学んだこととか思ったことなど時系列とか適当に書いてる。
テスト本読んでる
フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識を読んでた。
今大体9章くらいまで読み終えた。 最近そろそろテストかけないとやばいよなーと思っていたのでちょうどいい本やなと思い即ポチした。
最初らへんは簡単なテストについてのマッチャーとかから始まってコンポーネントのテストって感じで進んでいけるので肌感どういった感じでテストするかみたいなのは掴めると思う。
ただ、7章くらいの統合テストの話になると、急に置いてけぼり感を感じる。。
プロジェクトのコードクローンしてる前提で色々話してるから作りながら学ぶって感じではないかな。正直ここまでを作りながらってなると紙面の量がエグくなるのでしょうがないかなと思う。
色々テクニックがあると思うので盗めるところは盗みたい。
まったくテストやったことない人でも読めるけどReactを全く知らん人向けではないかな。一応やったことがあるぐらいやと全然読めると思う。
エラーやワーニングの解消してみた
ReactでTest時にWarning出てたのがちょっと気になったのでバージョン上げてみたりとかした。 → nextjsの方のプロジェクトはこれで治らなかった、エラーではないんやけど少し気になる…
あと、babelに関してもエラー出てたので追加したりしてた。
小さく作れるのが良い
テストをしてて思ったのは、今作ってるものに対して注力できること。DBに保存するとかAPIを叩くとかそういうものを作りながら実装していかなくてもモックにすることで作れなくても動かせるのが便利だなと思った。
動かせることで今作ってるものがちゃんと動くかだけに集中できるのがテストをやってて良いのかなってのはなんとなく理解した。集中できると小さいままで作れるから責務もわかりやすくなるのかな？
本を読むだけだとテストができる気はしないから、やっぱり書くのが良い。何を書けば良いか分からんってずっと思ってたけど、最初はマッチャーを見たりしながらそれを使うために適当な機能を考えてテストしながらいろんなマッチャーを試したりするのが良いのかなと思う。
本で紹介されてるコードは複雑だけど、結構重量感あるので何か適当に機能を考えて追加していきながらテストしてみるとかコンポーネントを少し変えてみるとかでテストを壊して直すとかやっていきたい。
リファクタリングに自信を持ってできる安心感を得られると楽しそう。
storybookが便利そう
storybookは名前だけ聞いてたけど、便利やな。いろんなコンポーネントの状態を保存して確認できるしそれ単体でちゃんと動いているかのテストとしても使える。バージョン6と7で少し使い方変わってるみたい。 mswも便利そうではあったけど、あんまりよくわかってない。jest.mockとの違いがいまいち理解できなかった。
アクセシビリティ
アクセシビリティを考慮したことなかって全然知らんかったけど、wai-ariaとかjestでコンポーネントを探したりする時にroleって概念があるみたい。 今後はこういうのもちゃんと考慮したコンポーネント作れると良さそう。
fieldsetとかタグ知らんかったし、、、HTMLやCSSもまだまだ知らんこと多いな。
userEventとfireEventの違い
userEventとfireEventでどちらもDOMのイベントを発火させれて何が違うのか分からんかったけど、userEventはユーザーが行うインタラクションに近い らしいので基本こっち使うで問題ないっぽい。
jest
snapshotはjest -uでアップデートできる。毎回ファイル消してたわ。
かなり、カナリー
canaryブランチ
カナリーって使われてて初めて聞いたので調べてみた。
カナリアリリースとは新バージョンのアプリケーションをリリースする際に、従来バージョンのアプリケーションを並行稼働させ、一部のユーザーだけを新バージョンにアクセスさせる展開（デプロイ）手法のこと。新バージョンにアクセスするユーザーを炭鉱で毒ガスを検知する「カナリア」に見立てて、この名称が付けられた。
同時並行させながら新しい方もアクセスするようにするものらしい。はえー。
準備、実行、確認
テストはこのArrange Act Assertのトリプルエーが大事らしい。これがちゃんと並んでるとみやすいし何をテストしているかがわかりやすい。
だからテストでif文使ったり何回もAAAが現れたりするくらいなら一度に多くのことをテストしてないかを疑うのが良いみたい。テストをわけたり。
網羅率が高いから良いテストではない
網羅率はコードの実行を網羅してるかifの分岐で分岐先どちらも実行できてるかどうかしか確認してないからテストしてないの可視化にはなるけど100パーセントだから良いテストではない。
100パーセントを維持して良いテストかけとか言われる環境だったら発狂しそう。
思ったこと
そこまでテストは難しいって感じではないんだなって思った。難しくしてるのは自分なのかもしれない。
テストをやるか、やらないかって極端な選択ではなくてできるところから始める自分が実装するコードはテストするとかできるところから始めるでもテストをすることは無駄にはならない。
ワイはテストを書く環境じゃなくても、今後はテストを書いていくのは大切にしたい。保守できないは言い訳な気がする。テストを保守できないってなるくらいなら後で全部テスト消せば良いだろうし。保守できないからテストしないは違うと思う。
なんしかやらないことには書けないし、書くために実装するコードをどう作るか調べるみたいにテストでもやれば良いんだろう。
テストかけたらあとは高める！
本の写経
@t_wadaさんのエンジニアの心構え読んだ。
自分も何か学んだことあればscrapboxにまとめて一日の終わりに振り返りついででこうやってブログを書くみたいなのをやろうと思って今日は書いてみた。
本の写経でとにかくコードを書いて実行したらコミット、章ごとにタグを切るって運用は見返した時に章のコードにすぐ移行できるから良いなって思った。 tagももっと使ってみたいと思う出来事であった。
最近CodeOwnersとかrulesetとかGitHub色々できることあってまだまだ使いこなせてないなって焦った… Copilotは便利すぎて禿げてる。
こういうのを書き続けて、 技術書典とかで同人誌的な感じで自分もいつか出せるといいなー。
基本めんどくさがりやから、具体的にブログにコードを書き連ねたりとかするんか知らんけど。
書きながら早く書いたり、必要なことだけをかけるスキルみたいなのを身につけていけたら良いな。 zennへのアウトプットも頑張らないと…
台風
テレビでピーピーずっとなっててそんなに台風やばいんってなってる。怖い。
感想
なんか今日やったことを適当に書くのって結構めんどくさいな。 流れも適当でって書いたけど、これここで書くん🤨って感覚が襲ってくる笑。
scrapboxで変更点みたいなのをDiscordで流すようにしてるけどこれまとめて今日やったことみたいな感じで出せたら書くの楽そう。
メモしよう、何か残しておこう、読んだならアウトプットしようって思うけど忘れるよねどうしたら忘れないようにできるのか...