私は製品で動作するチームに参加しました。この製品は約5年ほど前からあり、ASP.NET WebFormsを使用しています。その元のアーキテクチャは時間の経過とともに薄れており、ソリューション全体で物事は比較的混乱しています。それは決してひどいことではありませんが、確かにいくつかの仕事を使うことができます。あなたは皆私が何を意味するか知っています。既存システムのテスト容易化のためのリファクタリング
私は約6ヶ月前にプロジェクトチームへ来て以来、いくつかのリファクタリングを行ってきました。これらのリファクタリングのいくつかは、シンプル、抽出メソッド、プルメソッドアップなどです。リファクタリングのいくつかはより構造的です。後者の変更は、すべてのコンポーネントに付随する単体テストの包括的なスイートが存在しないので、私を緊張させるものです。
チーム全体がリファクタリングを通じて構造を変更する必要があるため、プロジェクトマネージャは回帰バグを導入しないという確信を持ってリファクタリングを行うための十分なテストがないという懸念を表明していますシステムに入力します。彼は最初に（既存のアーキテクチャに対して）より多くのテストを書いてから、リファクタリングを実行してほしいと思っています。私の主張は、システムのクラス構造が適切なテストを書くには密接に結合されていること、そしてリファクタリングを実行している間にテスト駆動型アプローチを使用する方が良いかもしれないということです。つまり、既存のコンポーネントに対するテストを作成するのではなく、特定の機能要件のテストを作成し、既存のコードをその要件を満たすようにリファクタリングすることです。これにより、「捨てる」テストをたくさん作成するのではなく、おそらくシステム内に長寿を持つテストを書くことができます。
誰もが最善の行動が何であるかについての任意の経験を持っていますか？私は自分の考えを持っていますが、コミュニティからの意見を聞きたいと思います。