성숙한 프로젝트에 TDD (Test Driven Development)를 도입하는 것이 가능합니까?

Question

• TDD 값이 너무 늦었다 고 가정 해 보겠습니다. 프로젝트는 이미 성숙되었고, 많은 고객이 프로젝트를 시작했습니다.
• 사용 된 자동 테스트는 주로 기능/시스템 테스트이며 자동화 된 GUI 테스트가 많이 있습니다.
• 새로운 기능 요청 및 새로운 버그보고 (!)가 있다고 가정 해보십시오. 따라서 여전히 많은 개발이 진행 중입니다.
• 단위 테스트가 없거나 적은 비즈니스 개체가 이미 많이 있습니다.
• 그들 사이에 너무 많은 공동 작업/관계가 있으며, 이들은 다시 상위 수준 기능/시스템 테스트를 통해서만 테스트됩니다. 그 자체로 통합 테스트가 없습니다.
• 테이블, 뷰 등이 많은 대규모 데이터베이스가 있습니다. 단일 비즈니스 오브젝트를 인스턴스화하기 위해 이미 데이터베이스 왕복 여행이 많이 있습니다.

어떻게이 단계에서 TDD를 도입 할 수 있습니까?

조롱은가는 길 같습니다. 그러나 우리가 여기서해야 할 조롱의 양은 너무 많이 보입니다. 정교한 인프라와 같은 소리는 기존 물건 (BO, 데이터베이스 등)을 위해 작업하는 조롱 시스템을 위해 개발해야합니다.

TDD는 처음부터 시작하는 경우에만 적절한 방법론을 의미합니까? 이미 성숙한 제품에 TDD를 도입하는 타당한 전략에 대해 듣고 싶습니다.

Answer 1

복잡한 조롱 기반 구조를 만들면 코드의 문제를 숨길 수 있습니다. 변경하려는 코드 기반의 영역에 대해 테스트 데이터베이스를 사용하여 통합 테스트를 시작하는 것이 좋습니다. 변경 사항을 적용해도 아무런 문제가 발생하지 않을 것이라는 충분한 테스트가 이루어지면 코드를 리팩터링하여 테스트를 쉽게 시작할 수 있습니다.

또한 Michael Feathers 우수 도서 Working effectively with legacy code은 TDD를 기존 코드 기반에 도입 할 생각이있는 사람이라면 누구나 읽을 수 있어야합니다.

Answer 2

가능합니다. 한 번에 모든 것을 수행하지 말고 모듈을 만질 때마다 모듈을 테스트하는 데 필요한 것을 소개하십시오.

더 높은 수준의 수락 테스트를 시작하고 거기에서부터 진행할 수도 있습니다 (이 경우 Fitnesse을보세요).

Answer 3

TDD를 기존 응용 프로그램에 도입하는 것이 완전히 가능하다고 생각합니다. 사실 최근에 직접 작성했습니다.

TDD 방식으로 새로운 기능을 코딩하고이를 수용하기 위해 기존 코드를 재구성하는 것이 가장 쉽습니다. 이렇게하면 테스트 된 코드의 작은 부분부터 시작할 수 있지만 효과는 전체 코드 기반으로 확산되기 시작합니다.

버그가 있다면, 그것을 재현하기위한 단위 테스트를 작성하고, 필요하다면 코드를 리팩토링하십시오 (실제로 노력하지 않는 한).

필자는 개인적으로 미친 듯이 나아가고 기존 시스템에 시험을 추가하거나 개조해야 할 필요가 없다고 생각합니다. 많은 이점이 없이는 지루할 수 있습니다.

요약하면, 작게 시작하면 프로젝트는 점점 더 감염 될 것입니다.

Answer 4

가능합니다.귀하의 설명에서 프로젝트는 좋은 모양입니다 - 기능 테스트 자동화의 견고한 금액은 갈 방법입니다! 어떤면에서는 단위 테스트보다 훨씬 유용합니다. TDD! = unit testing이라는 것은 짧은 반복과 확실한 수용 기준에 관한 것입니다.

실제로 존재하고 받아 들여진 프로젝트가 실제로 테스트를 더 쉽게 만듭니다. 작동하는 응용 프로그램이 최상의 요구 사항 사양입니다. 그래서 당신은 일할 종이 조각을 가지고있는 누군가보다 더 나은 위치에 있습니다.

TDD로 새로운 요구 사항/버그 수정 작업을 시작하십시오. 방법론을 전환하는 데 따른 오버 헤드가 발생한다는 사실을 기억하십시오 (고객이이 사실을 알고 있는지 확인하십시오!) '좋은 옛날 방식'에 익숙한 팀원은 많은 기대를하지 않을 것입니다.

필요없는 경우 이전 물건을 만지지 마십시오. 기존 물건에 영향을 줄 수있는 개선 요청이있는 경우 추가 설정 작업을 수행하는 데 추가 시간을 고려하십시오. 개인적으로

나는 모형에 대한 복잡한 인프라를 소개하는 많은 값이 표시되지 않습니다 - 확실히 경량 모드에서 동일한 결과를 얻을 수있는 방법이 있지만, 분명히 상황에 따라

Answer 5

내가 시작할 것 몇 가지 기본적인 통합 테스트가 있습니다. 이것은 직원의 나머지 부분에서 바이 인을 얻을 것입니다. 그런 다음 종속성이있는 코드 부분을 분리하기 시작합니다. Dependency Injection을 사용하면 코드를 훨씬 더 테스트 가능하게 만들 수 있습니다. 테스트 가능한 코드를 작성할 수있는 기회로 버그를 다루십시오.

Answer 6

레거시 코드를 테스트하는 데 도움이되는 도구 (typemock 격리 자 : Typemock.com : )는 인터페이스를 추출하지 않고도 기존 코드에 종속성을 주입 할 수 있습니다 (동적 프록시 등 ..)을 사용하지 않기 때문에 프로파일 러 API를 대신 사용합니다. 공유 지점, HTTPContext 및 기타 문제가있는 영역에 의존하는 앱을 테스트하는 데 사용되었습니다. 나는 당신을 한번 보시기를 권합니다. (해당 회사의 개발자로 일하지만, 기존 레거시 코드를 리팩터링하지 않아도되므로 시간과 비용을 절약 할 수 있습니다) 더 많은 기술에 대해서는 "레거시 코드로 효과적으로 작업"을 적극 권장합니다. .

Roy