기존 시스템의 테스트 가능성을 위한 리팩토링

Question

저는 제품을 담당하는 팀에 합류했습니다.이 제품은 약 5년 정도 출시되었으며 ASP.NET WebForms를 사용합니다.원래 아키텍처는 시간이 지남에 따라 희미해졌으며 솔루션 전반에 걸쳐 상황이 상대적으로 혼란스러워졌습니다.결코 끔찍한 것은 아니지만 확실히 약간의 작업을 사용할 수 있습니다.무슨 말인지 다들 아시죠?

저는 약 6개월 전 프로젝트 팀에 합류한 이후 몇 가지 리팩토링을 수행해 왔습니다.이러한 리팩토링 중 일부는 간단하고 Extract Method, Pull Method Up 등이 있습니다.일부 리팩토링은 보다 구조적입니다.후자의 변경 사항은 모든 구성 요소에 수반되는 포괄적인 단위 테스트 모음이 없기 때문에 긴장됩니다.

전체 팀이 리팩토링을 통해 구조적 변경을 수행해야 한다는 점에 동의했지만 프로젝트 관리자는 시스템에 회귀 버그를 도입하지 않는다는 확신을 갖고 리팩토링을 수행할 적절한 테스트가 없다는 몇 가지 우려를 표명했습니다.그는 우리가 먼저 (기존 아키텍처에 대해) 더 많은 테스트를 작성한 다음 리팩토링을 수행하기를 원했습니다.내 주장은 시스템의 클래스 구조가 적절한 테스트를 작성하기에는 너무 밀접하게 결합되어 있으며 리팩토링을 수행하는 동안 테스트 기반 접근 방식을 사용하는 것이 더 나을 수 있다는 것입니다.이것이 의미하는 바는 기존 구성 요소에 대한 테스트를 작성하는 것이 아니라 특정 기능 요구 사항에 대한 테스트를 작성한 다음 해당 요구 사항을 충족하도록 기존 코드를 리팩터링하는 것입니다.이를 통해 우리는 '버리는' 테스트를 여러 개 작성하는 대신 시스템에서 더 오래 지속될 수 있는 테스트를 작성할 수 있습니다.

최선의 행동 방침이 무엇인지 경험이 있는 사람이 있습니까?저만의 생각이 있지만 커뮤니티의 의견도 듣고 싶습니다.

Answer 1

PM의 우려는 타당합니다. 주요 리팩토링을 수행하기 전에 시스템을 테스트해 보시기 바랍니다.

나는 Michael Feather의 책을 한 권 구입하는 것을 강력히 추천합니다. 레거시 코드로 효과적으로 작업하기 ("레거시 코드"에서 깃털은 단위 테스트에서 적절하게 다루지 않는 모든 시스템을 의미합니다).이것은 회귀 버그가 발생할 위험이 없는 안전한 방식으로 당신이 말하는 결합과 종속성을 분해하는 방법에 대한 좋은 아이디어로 가득 차 있습니다.

리팩토링 프로그램에 행운이 있기를 바랍니다.내 경험상 그것은 많은 것을 배울 수 있는 즐겁고 카타르시스적인 과정이다.

Answer 2

병렬로 리팩토링할 수 있나요?내 말은 TDD를 사용하여 리팩토링하려는 부분을 다시 작성하되 기존 코드 베이스는 그대로 두라는 것입니다.그런 다음 새 테스트가 PM의 요구 사항을 충족하면 기존 코드를 단계적으로 폐지하시겠습니까?

Answer 3

저도 한 번 방문해 보라고 제안하고 싶습니다. 리팩토링 마틴 파울러의 웹사이트.그는 말 그대로 이 문제에 관해 책을 썼습니다.

방정식에 단위 테스트를 도입하는 한 내가 찾은 가장 좋은 방법은 최상위 구성 요소를 찾아 구체적인 개체에 대한 모든 외부 종속성을 식별하고 이를 인터페이스로 바꾸는 것입니다.이 작업을 수행하고 나면 코드 기반에 대한 단위 테스트를 작성하는 것이 훨씬 더 쉬울 것이며 한 번에 하나의 구성 요소를 수행할 수 있습니다.더 좋은 점은 단위 테스트를 버릴 필요가 없다는 것입니다.

단위 테스트 ASP.Net은 까다로울 수 있지만 이를 더 쉽게 수행할 수 있는 프레임워크가 많이 있습니다. ASP.Net MVC, 그리고 WCSF 몇 가지 예를 들자면.

Answer 4

Working Effectively with Legacy Code에 대한 두 번째 권장 사항을 제시합니다. 이 책은 거의 모든 오래되고, 형편없고, 테스트할 수 없는 코드가 랭글링될 수 있다는 사실에 눈을 뜨게 해 준 훌륭한 책입니다!

Answer 5

님의 답변에 전적으로 동의합니다. 이안 넬슨.또한 사용자의 관점에서 동작을 보존하기 위해 일부 "높은 수준" 테스트(기능 또는 구성 요소 테스트)를 시작했습니다.이 점이 PM에게 가장 중요한 관심사일 수 있습니다.