E2Eテストで挫折しそう？どうしているかを話してみた

Рет қаралды 6,966

ムーザルちゃんねる

Күн бұрын

Пікірлер

@yamcha0327 4 ай бұрын

めちゃくちゃ有益なコンテンツありがとうございます。今の自分に一番必要なチャンネルです！😊

@nya3mo 4 ай бұрын

現場のガチE2Eテスト論、めちゃめちゃ参考になりました・・・

@kumonopanya 4 ай бұрын

学んだことカバレッジ１００％よりも変化がある重要部分にテストを書け

@akirakataoka8885 3 ай бұрын

Web素人の私にとっては、横文字ワードがカッコいいです。

@HIBIKICUBE 4 ай бұрын

ある動作や仕様について、コンポーネントテストとE2Eのどっちで確認すべきなのか、あるいは両方で確かめるべきなのかで悩むことは時々ありますね〜皆さんはどうしてるんでしょうか。自分は極力コンポーネントテストで確かめて、そこで確認できないこと(CSSが絡むものとか)はPlaywright使うようにしていたりします。あとはコンポーネントやページを跨いだ動作とか

@moozaru 4 ай бұрын

そうですね、極力コストの低いテストコード比重を増やしたいのでE2Eは、E2Eじゃないとダメなところだけ書きたいですね。コンポーネントやユニットテストをきちんと書けば大抵の不具合は検知できたりするので。あとはReactのServerComponent（非同期）対応が各種テストツールで進むことを期待しましょう。

@TaiyoSuzuki-w4d 4 ай бұрын

このお二人の会話なんか聞けてしまう…

@SETO-LAB 3 ай бұрын

待ってくれるはずのプレイライト画面遷移のテストがどうしてもfreakyでした。なんでだったんだろう…

@masleisii 4 ай бұрын

E2Eテストというよりはテスト全般におけることなのですが、「正しいテストが書けているか」というのはどうやって保証しますか？

@moozaru 4 ай бұрын

これは難しい問題だなと思いますが、僕の考えでは「テストコードは正しさを完全に証明するものではない」と捉えています。テストコードに限らず完璧なコードを書くことは現実的には無理です。となると正しいと保証されていないテストコードを書く意味はあるのか？という問いになりますが、これは「ある」と思っています。主に以下の観点です。・テストコードを書くことで気が付かなかった仕様ミスや実装ミスに気が付ける・テストコードは実装のドキュメントになり得る・何回も繰り返される動作確認を効率的に行える完全ではないかもしれないが、それでも価値は高いという感覚ですね。あとはテストコードもちゃんと保守し続けると言う意識が開発チームに根付いていくことも重要だと考えています。と偉そうなことをコメントしましたが、実際にやり切れているかは別でめちゃ難しいですねーw

@masleisii 4 ай бұрын

回答ありがとうございます！「テストコードは正しさを完全に証明するものではない」と聞いてちょっと気が楽になりました。テストは完全じゃないといけないとどこか思っていた節があったので。・テストコードを書くことで気が付かなかった仕様ミスや実装ミスに気が付ける・テストコードは実装のドキュメントになり得る・何回も繰り返される動作確認を効率的に行えるなるほど、これらも「確かに！」と思えることばかりですね。

@senken32 3 ай бұрын

横から勝手に個人的な意見を言うと、チーム開発においては「正しくテストが書けていなかった」場合は以下のケースに当てはまると思っています 1. 仕様が不明瞭、仕様書がちゃんとしていない 2. テストコードの書き方をチーム内で統一できていない 3. そもそもテストコード文化が浸透していない 4. 本人の技術不足特に 1 は慣れていても起こりがちですね

@null776 2 ай бұрын

server actions使ってる場合は、書けそうな部分は単体テスト、結合テストを書いて、難しい部分はE2Eでカバーするといった感じでしょうか。

@moozaru 2 ай бұрын

そうですね。Server Actionsの内部ロジックを別関数に切り出すなどをすると、通常のユニット（DBがあるなら結合）テストで、全体のフローをチェックしたい場合はE2Eですね。あとはServerComponentのコンポーネントテストが簡単にかけるようになったら、一通りテスト手法は安定しそうです。