TDD를 사용할 때 기능을 제거하는 방법

TDD에 관한 텍스트에서 리팩토링 단계에서 종종 "중복 제거"또는 "가독성 향상"에 대해 읽습니다. 그러나 사용하지 않는 기능을 제거하는 이유는 무엇입니까?

예를 들어, C메소드 a()와 클래스가 있다고 가정 해 봅시다 b(). 이제에 도입 된 방법을 사용 f()하는 것이 좋을 것이라고 생각합니다 C. 실제로 정의 / 설명 된 단위 테스트를 제외한 f()모든 호출을 대체합니다 . 테스트를 제외하고는 더 이상 필요하지 않습니다.b()b()

그것을 제거 b()하고 그것을 사용한 모든 테스트에 저장 됩니까? "가독성 향상"의 일부입니까?

물론입니다. 가장 쉬운 코드는 존재하지 않는 코드입니다.

즉, 리팩토링은 일반적으로 동작을 변경하지 않고 코드를 개선하는 것을 의미합니다. 코드를 향상시키는 무언가를 생각하면 그냥 해보십시오. 당신이 그것을 허용하기 전에 비둘기 구멍에 맞출 필요가 없습니다.

공용 메소드를 제거하는 것은 "리팩토링"이 아닙니다. 리팩토링은 기존 테스트를 계속 통과하면서 구현을 변경합니다.

그러나 불필요한 방법을 제거하는 것은 디자인이 완전히 합리적입니다.

테스트를 검토 할 때 불필요한 메소드를 테스트하는 것을 관찰 할 수 있기 때문에 TDD는이를 어느 정도 끌어냅니다. "이 테스트는 내 목표와 아무 관련이 없습니다"라고 갈 수 있기 때문에 테스트가 설계를 주도하고 있습니다.

코드 범위 도구와 함께 더 높은 수준의 테스트에서 더 많이 드러날 수 있습니다. 코드 적용 범위로 통합 테스트를 실행하고 메소드가 호출되지 않는 것을 확인하면 메소드가 사용되지 않는다는 단서입니다. 정적 코드 분석은 메소드가 사용되지 않음을 나타낼 수도 있습니다.

메소드를 제거하는 방법에는 두 가지가 있습니다. 둘 다 다른 상황에서 작동합니다.

1. 방법을 삭제하십시오. 컴파일 오류에 따라 종속 코드 및 테스트를 삭제하십시오. 영향을받는 테스트가 일회용인지 확인한 경우 변경 사항을 커밋하십시오. 그렇지 않은 경우 롤백하십시오.

2. 쓸모 없다고 생각되는 테스트를 삭제하십시오. 코드 적용 범위로 전체 테스트 스위트를 실행하십시오. 테스트 스위트에서 실행하지 않은 메소드를 삭제하십시오.

(이것은 테스트 스위트가 시작하기에 좋은 커버리지를 전제로합니다).

실제로 f ()는 b ()를 정의 / 설명한 단위 테스트를 제외하고 b ()에 대한 모든 호출을 대체합니다.

일반적인 TDD주기는 다음과 같습니다.

• f ()에 대한 실패한 테스트 작성 (아마도 b ()에 대한 테스트를 기반으로 함) : 테스트가 빨간색으로 바 go

• f () 구현-> 테스트가 녹색이 됨

• 리 팩터 :-> b () 및 b ()에 대한 모든 테스트 제거

마지막 단계에서는 먼저 b ()를 제거하고 어떤 일이 발생하는지 확인하십시오 (컴파일 된 언어를 사용하는 경우 컴파일러는 기존 테스트에 대해서만 불평해야합니다. 그렇지 않은 경우 b에 대한 이전 단위 테스트는 실패하므로 제거해야합니다).

그렇습니다.

가장 버그가없고 가장 읽기 쉬운 코드는 존재하지 않는 코드입니다. 요구 사항을 충족시키면서 가능한 한 많은 비 코드를 작성하도록 노력하십시오.

b()사용하지 않는 기능을 처음에 추가하지 않는 것이 바람직하기 때문에 더 이상 사용하지 않으면 제거 하는 것이 좋습니다. 당신이 그것을 "가독성"이라고 부르든, 다른 것들과 동등하든 그것은 그것이 사용하지 않는 것을 포함하지 않는 코드를 개선하는 것입니다. 그것을 갖지 않는 것이 더 나은 적어도 하나의 특정 조치를 취하기 위해, 그것을 제거하면 그 변경 후의 미래 유지 보수 비용이 0임을 보장합니다!

b()새로운 것으로 대체 할 생각 은 물론 현재 호출하는 모든 코드를 고려해야 b()하며 테스트는 "모든 코드의 하위 집합 이기 때문에 필자는 실제로 테스트와 함께 제거하는 데 필요한 특별한 기술을 찾지 못했습니다. ".

일반적으로 나를 위해 작동하는지 추론의 라인이 시점에서 내가 그 통지 곳이다 f()만들었다 b()따라서 오래된 b()적어도되지해야한다, 나는 모든 전화를 찾기 위해 찾고 있어요 b()호출로 대체 의도로 f(), I 테스트 코드도 고려하십시오 . 특히, b()더 이상 필요하지 않은 경우 단위 테스트를 제거 할 수 있으며 제거해야합니다.

더 이상 필요하지 않은 것을 강제로 알려주는 것이 아무것도 없다는 것이 맞습니다 b(). 그것은 기술의 문제입니다 (슬림이 말했듯이 코드 범위는 높은 수준의 테스트에 대해보고합니다). 기능 테스트가 아닌 단위 테스트 만 참조 b()하면 게시 된 인터페이스의 일부가 아니므로주의 깊게 낙관 할 수 있으므로 직접 제어하지 않는 코드에 대한 주요 변경 사항은 아닙니다.

레드 / 그린 / 리 팩터 사이클은 테스트 제거를 명시 적으로 언급하지 않습니다. 또한, 제거 b()하기 위해 구성 요소 가 명확하게 열려 있기 때문에 제거 는 개방 / 폐쇄 원칙을 위반합니다 . 따라서이 단계를 단순한 TDD 외부의 것으로 생각하려면 계속 진행하십시오. 예를 들어, "나쁜"테스트를 선언하는 프로세스가있을 수 있습니다.이 경우이 테스트는 적용해서는 안되는 무언가 (필수 기능 b())를 테스트하는 근거에서 테스트를 제거 할 수 있습니다 .

실제로 대부분의 사람들은 아마도 레드 / 그린 / 리 팩터 사이클과 함께 일정량의 재 설계를 수행 할 수있을 것이라고 생각합니다. 리팩토링이 아닙니다. 귀하의 팀은이 결정을 정당화하는 데 얼마나 많은 드라마와 서류 작업이 필요한지를 결정할 수 있습니다.

어쨌든 b()중요한 경우 기능 테스트가 있었으며 가볍게 제거되지는 않았지만 이미 단위 테스트 만 있다고 말했습니다. 단위 테스트 (변경된 코드의 현재 내부 디자인에 작성)와 기능 테스트 (변경되지 않은 게시 된 인터페이스에 작성)를 제대로 구분하지 않으면보다 신중해야합니다. 단위 테스트 제거에 대해

항상 기억해야 할 것은 현재 VERSION CONTROL과 함께 코드 저장소를 사용하고 있다는 것입니다. 삭제 된 코드는 실제로 사라지지 않았습니다 ... 이전 반복의 어딘가에 여전히 있습니다. 날려 버려! 삭제 키를 사용하면 자유 로워 질 수 있습니다. 언젠가는 언제라도 유용 할 것으로 생각되는 귀중한 우아한 방법을 언제든지 다시 검색 할 수 있기 때문입니다. 저기에있어.

물론, 이는 이전 버전과 호환되지 않는 릴리스의 악의와 경고와 함께 진행됩니다. 인터페이스 구현에 의존하는 외부 응용 프로그램은 이제 (갑자기) 사용되지 않는 코드에 의해 분리됩니다.