テスト自動化失敗談を共有しよう！ by T-DASH カレンダー、2日目の記事になります。 はじめに E2Eテストを書きましょう！とチームで決意し、実際に書いてみたものの、気づけばいつのまにか通らなくなっており、誰も直さないうちにそのまま忘れ去られる……というのは、E2Eテスト自動化のあるあるだと思います。 この記事では、メンテナブルなE2Eテスト実装について、一般的に言われることと、自身の失敗経験とを照らし合わせてみたいと思います。 E2Eテストについて ここでE2Eテスト（End to Endテスト）と呼んでいるものは、なんらかのUI操作自動化ライブラリ（UI Automation, Puppeteer, Cypressなど）を使い、コードとしてユーザー操作シナリオをエミュレートするテストのことを言っています。 特に、ノーコードのシナリオ自動生成ツール利用を検討する場合は別のソリューシ

「レガシー」を保守したり、刷新したりするにあたり得られた知見・ノウハウ・苦労話 by Works Human Intelligence カレンダー、3日目の記事になります。 はじめに プロダクトや開発環境に限らず、どんな会社にも多かれ少なかれレガシーなメソッドがレガシーなまま残っているものです。 だれも見ていない予定表に記入するルール、冗長な二重の申請手続き、印刷した紙ベースでのコードレビューetc. 何をレガシーとするかは主観による部分も大きいですが、誰もが「これ意味あるの？」「もっといい方法ないの？」と思いつつ、なんとなく続けられている規則もあるでしょう。 そういったレガシーをどうやってカイゼンしていくか、という話になります。 どんなレガシーがあるか イメージをもっていただきやすいように、実際に過去に遭遇し、自分または周囲の人がカイゼンを試みたレガシーな社内メソッドを挙げてみます。 社