단위 테스트를 추가하는 것이 잘 알려진 레거시 코드에 적합합니까?

• TDD 의미에서 단위 테스트 에 대해 이야기하고 있습니다. (자동화 된 "통합"또는 테스트라고하는 것은 아닙니다.)
• 테스트가없는 (C ++) 코드와 같은 레거시 코드 (Michael Feathers의 레거시 코드로 효과적으로 작업하기 참조 )
• 또한 레거시 코드는 다음과 같습니다. 지난 10-5 년 동안 우리 팀이 협력해온 코드이므로 변경해야 할 사항을 어디에 두어야하는지에 대한 좋은 아이디어가 있습니다.
• 우리 는 나중에 나왔거나 단위 테스트 (일반적인 응용 프로그램 특정 컨테이너, 문자열, 네트워크 도우미 등)에 "자연스럽게"적합했던 일부 모듈에 대해 단위 테스트를 실시했습니다 (부스트 테스트를 통해 ).
• 아직 적절한 자동 수락 테스트가 없습니다.

최근에는 3 가지 새로운 사용자 대면 기능을 구현할 수있는 "즐거움"이있었습니다.

그 각각은 내가 변경 해야하는 코드 부분, 1-2 시간 동안 변경 해야하는 (작은) 코드를 구현하는 데 1-2 시간, 앱을 확인하는 데 1-2 시간이 걸리는 데 약 1-2 시간이 걸렸습니다. 그 후에 올바르게 달려서해야했습니다.

이제 작은 코드를 추가했습니다. (각 기능마다 하나의 방법과 몇 개의 전화 회선이 있다고 생각합니다.)

(에 제안 된 방법 중 하나를 통해이 코드 밖으로 인수 분해 WEwLC을 했을 단위 테스트는 메이크업 감각을 텐데 그래서 () 및 완전한 동의어 반복하지) 쉽게 하지 많은 경우, 다른 2-4시간을 촬영. 이것은 각 기능에 50 % -100 %의 시간을 추가했을 것입니다.

1. 코드에 대해 이해하기 위해 단위 테스트가 필요하지 않았습니다.
2. 수동 테스트는 코드가 앱의 나머지 부분에 올바르게 통합되어 있는지 테스트해야하기 때문에 동일한 양의 작업입니다.

, 부여 하면 나중에, "누군가가"함께 와서 코드, 그는 감동을, 이론적으로 그 단위 테스트에서 몇 가지 이점을 가질 수있다. (이론적으로 테스트 된 코드 아일랜드는 테스트되지 않은 코드의 바다에 살 것입니다.)

따라서 이번에는 단위 테스트를 추가하는 데 어려움을 겪지 않기로 결정했습니다. 테스트중인 항목을 얻기위한 코드 변경은 기능을 올바르게 ( 정확하게 ) 구현 하기위한 코드 변경보다 훨씬 더 복잡했을 것 입니다.

이것이 강력하게 결합 된 레거시 코드에 일반적인 것입니까? 나는 게 으르거나 팀으로서 잘못된 우선 순위를 설정합니까? 아니면 오버 헤드가 너무 높지 않은 물건 만 테스트하는 것이 신중합니까?

이러한 상황에 대해 실용적이어야합니다. 모든 것이 비즈니스 가치를 가져야하지만, 비즈니스는 기술 작업의 가치가 무엇인지 판단해야합니다. 그렇습니다. 단위 테스트를하면 항상 이점이 있지만 그 시간이 시간을 정당화하기에 충분할까요?

나는 항상 새로운 코드를 주장 하지만 레거시 코드에서는 판단을해야합니다.

이 코드 영역에 자주 있습니까? 그런 다음 지속적인 개선이 필요한 경우가 있습니다. 당신은 중대한 변화를하고 있습니까? 그런 다음 이미 새로운 코드 인 경우가 있습니다. 그러나 복잡한 지역에서 1 년 동안 다시는 손대지 않는 한 줄짜리 코드를 작성하는 경우 물론 리엔지니어링 비용 (위험은 말할 것도없고)이 너무 큽니다. 한 줄의 코드를 넣고 샤워를 빨리하십시오.

경험의 규칙 : 항상 " 내가 생각하는 업무보다 결과적으로 지연 될이 기술 업무의 이점이 비즈니스에 더 도움이된다고 생각합니까? "

TDD 의미에서 단위 테스트의 이점은 안정적인 팀이 수년에 걸쳐 구축 한 구전 전통을 필요로하지 않고 자체적으로 뛰어난 것을 얻는 것입니다.

같은 팀이 오랫동안 같은 프로젝트에 참여한 것은 큰 행운입니다. 그러나 이것은 결국 변할 것입니다. 사람들은 아프거나 지루하거나 승진합니다. 그들은 움직이거나 은퇴하거나 죽습니다. 새로운 아이디어는 새로운 아이디어와 함께 학교에서 배운 방식대로 모든 것을 리팩토링하려는 욕구를 가지고 있습니다. 회사는 팔리고 삽니다. 관리 정책이 변경되었습니다.

프로젝트를 생존 시키려면 변경을 위해 프로젝트를 준비해야합니다.

단위 테스트 작성은 나중에 코드를 교정하는 것입니다. 코드베이스에 테스트가없는 경우 모든 새로운 기능에 대해 새로운 테스트를 추가해야합니다. 왜냐하면 코드의 비트가 조금 더 강력 해지기 때문입니다.

레거시 코드에서도 테스트를 추가하는 것이 중장기 적으로 유리하다는 것을 알았습니다. 귀사가 중장기 적으로 신경 쓰지 않는다면 다른 회사를 찾겠습니다. 또한 세트 단위 테스트를 작성하는 것보다 수동으로 테스트하는 데 시간이 오래 걸리지 않습니다. 그렇다면 테스트 작성에 중점을 둔 코드 카타를 연습해야합니다.

확실히 모범 사례는 변경 한 코드를 단위 테스트해야한다는 것을 나타냅니다. 그러나 실제 코딩에는 많은 타협이 필요하며 시간과 자료는 제한적입니다.

실제로 버그를 수정하고 단위 테스트없이 수정하는 비용을 평가해야합니다. 그런 다음 해당 테스트 작성에 대한 투자에 대해 평가할 수 있습니다. 단위 테스트는 향후 작업 비용을 크게 줄이지 만 지금은 가격이 책정됩니다.

결론은 시스템이 거의 변경되지 않으면 단위 테스트를 작성할 가치가 없지만 정기적으로 변경되는 경우 가치가 있습니다.

테스트를하지 않기위한이 합리적 결정은 모두 누군가를 떠날 때와 새로운 직원이 와서 속도를 낼 때 당신을 괴롭히는 심각한 기술적 부채를 만들어 내고 있습니다.

예, 단위 테스트를 작성하는 데 2-3 시간이 더 소요될 수 있지만 테스트에서 코드를 다시 보내면 모든 것을 수동으로 다시 테스트하고 테스트를 다시 문서화해야합니다. 그렇지 않습니까? 그렇지 않으면 테스트 한 내용과 사용한 값을 어떻게 아는 사람이 있습니까?

단위 테스트는 기능을 확인하기 위해 테스트 데이터가 사용한 코드의 예상 동작을 문서화하고 새로운 코더가 변경 작업을 수행 할 때 어떤 문제가 발생하지 않았다는 확신을줍니다.

오늘날 수동 테스트보다 몇 시간이 걸리지 만 코드 수명 동안 변경 시간을 절약 할 때마다 테스트하고 있습니다.

그러나 코드가 2 년 안에 폐기 될 것이라는 것을 알고 있다면 코드에 테스트를 완료하지 않고 결코 갚지 않을 것이기 때문에 변경 사항을 언급했습니다.

단위 테스트의 가치는 새로운 기능이 개발 될 때 테스트하는 것만이 아닙니다. 단위 테스트의 이점은 대부분 미래에 얻을 수 있습니다.

예, 당신은 무엇을 지출 할 수 있습니다 보인다 기존 코드를 검증 할 시간의 과도한 양처럼.

그러나 그렇지 않은 경우 기능을 테스트하는 데 많은 시간, 더 많은 시간을 소비 해야 합니다. 초기 개발뿐만 아니라 모든 새 버전의 소프트웨어와 함께 제공됩니다. 단위 테스트없이 다른 형태의 자동 테스트를 수행하지 않으면 다른 옵션이 없지만 해당 기능 자체가 변경되지 않은 경우에도 기능이 실수로 손상되지 않았는지 확인하기 위해 많은 시간의 수동 테스트를 수행해야합니다.