元にスナップショットをとり、コミット毎の差分を検知します。無効とすることで無駄なスナップショットを抑えました。比重を高くしています。Trophy上の比重の多いIntegrationTest(VRT)の領域を、Storybookで実装する今回、エンジニア以外の職種含む別チームのサポートメンバーにもテスト実装をお願いすることにしました。そのためコーディングに馴染みのないサポートメンバーにもテストが書きやすい環境を用意する必要がありました。ステップ毎に現状を把握するのが容易になります。起動できればブラウザの開発者ツール等を用いてデバック可能なため、環境構築の面でも障壁を下げることができました。そのまま流用できることがわかっていました。導入は良い選択だったと感じています。テストを実行した結果は以下の通りです。割程度というかなりの量のテストがサポートメンバーによって実装され、無事リリースまでに必要なテストの自動化を終えることができました。再利用することができました。「実際に動く画面で確認できるので実装・デバッグしやすい」「エラーのタイミングわかりやすい」といったフィードバックがありました。ないケースでテストが落ちる場合の画面の状態の調査など、詰まりやすいポイントで視覚的な効果を発揮できたようです。よるテスト実装の課題もいくつかあります。比較すると実行速度がかかることが予想されます。とそこまで大きな負荷にはなっていませんが、将来的に実装やテストが拡充した場合ボトルネックになる可能性があります。jest.mockを用いることができません。手法を採用する必要がありました。する例が紹介されていますが、やや煩雑な印象です。利用する必要があります。バージョンに依存するライブラリが多く、これらのパッケージの管理(定期的なアップデートや依存関係の整理)にコストを感じる場面がありました。毎にビルドを分割できませんでした。先行で利用するには下記の設定を追加します。デフォルトで有効になっているため、上記の設定は不要です。Previewなどのより軽量なシステムで視覚的なわかりやすさを実現することを検討しています。テストファイルに差し込むことで、ローカル上でpreview.debug()が実行された時点の画面状態を確認することが可能になります。よるテスト実装を行いました。操作が非常に好評で、視覚的なわかりやすさによってテスト実装の敷居を大幅に下げることに成功しました。辛さや実行コスト、メンテコストなど、長期的に考えると不安な要素もあります。チームの状況によってテストツール(テストに限りませんが)の最適な選択は変わっていきます。今後も変化していくチームに合わせてより最適なテスト手法を模索していきたいです。いった面では、フロリアのようにチーム単位で細かく意思決定できることの重要さを改めて実感する良い機会となりました。フロリアでは絶賛メンバーを募集しています。フロントエンド刷新に興味がある、開発環境を一緒に良くしていきたいという方はぜひ応募してみてください。採用した話こんにちわ。フロントエンドエキスパートチームの@nus3_です。cli-kintoneのテス...こんにちは。プロダクトセキ...こんにちは!Cy-PSIRTの田口です。プロダクトセキュリテ...2024-11-05kintoneライターチームのチームビルディング開...こんにちは。テクニカルライターチームのueです。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。