답변:
모든 단위 테스트가없는 것보다 낫습니다. 따라서 그것은 전혀 또는 전혀 거래가 아닙니다.
귀하의 경우 테스트 주도 개발이 표준이 아니기 때문에 테스트가 어떻게 사용되는지 궁금 할 것입니다.
앞으로 작성 하는 모든 코드가 (현재) 기능을 중단하지 않도록 하고 하위 사례를 편리하게 사용할 수 있도록합니다. 잘 작성된 테스트를 통과하면 아무 것도 손상되지 않은 것입니다. 다음에 오는 개발자는 테스트와 문서에 감사드립니다.
시작할 수있는 것은 계층 구조가 잘 분할되어 있고 데이터 액세스 계층을 선택하고 테스트를 통해 위쪽 (UI 계층쪽으로)으로 작업하는 것입니다. 프로젝트에 도메인 모델이있는 경우 대부분의 논리를 가질 가능성이 가장 높은 TDD 후보입니다. 서비스 (또는 비즈니스 로직) 티어가 단지 도메인 / 데이터 액세스 티어를 호출하는 경우 TDD 방식으로 서비스 티어를 수행하는 데 아무런 의미가 없습니다. 그것들은 모호한 테스트이며별로 가치가 없습니다.
Emma와 같은 코드 범위 도구에 추가되어 전반적인 테스트 범위의 개선 사항을 꾸준히 모니터링 할 수 있습니다.
나는 초기에 단위 테스트가 없었던 매우 큰 코드베이스에서 일했습니다. 몇 몇 관행에 따라 몇 가지 사례를 따르면 대부분 코드 기반을 테스트 할 수 있습니다.
모든 새 코드에는 단위 테스트가 있어야합니다.
변경된 모든 코드에는 단위 테스트가 추가되어야합니다.
이전 코드를 테스트하지 않고 안전하게 테스트를 추가하는 방법은 주로 다음 기본 접근 방식을 사용하는 것입니다.
기능을 변경해야하는 작은 코드 섹션을 선택하십시오.
변경중인 코드를 테스트하기 위해 필요한 인터페이스를 소개하십시오. 신뢰도가 높은 매우 작은 변경 순서로 구성된 리팩토링 기술을 사용하십시오. 가능하면 공구 지지대를 사용하십시오. 예를 들어, 변경중인 메소드를 자체 오브젝트로 이동 / 추출하여이를 수행 할 수 있습니다. 되돌릴 수 있도록 정기적으로 변경 사항을 확인하십시오. 개정 관리 기록을 통해 변경 사항을 정기적으로 동료 검토하십시오.
테스트 추가를 방해하는 종속성을 없애기 위해 필요한 변경 사항을 최소화하십시오.
우리는이 일을 많이할수록 쉬워진다는 것을 알았습니다. 코드베이스로 돌아갈 때마다 조금 더 좋습니다.
QA 테스터에게 발생하는 버그 수가 크게 줄었습니다. 기능 회귀는 거의 들어 보지 못 했으므로 우리에게는 그만한 가치가 있다고 생각합니다.
오래된 것들이 수년간 잘 작동했다면, 오래된 것들에서 무언가를 바꾸지 않는 한 지금 단위 테스트를 만드는 것은 필수적이지 않습니다. 어쨌든 새로운 부품에 대한 단위 테스트 작성은 전혀 의미가 없습니다. 새로운 부분은 버그를 포함 할 가능성이 가장 높은 부분이며 변경되거나 리팩토링 될 가능성이 가장 큰 부분입니다.
현재 코드를 다루기 시작하고 시간이 있으면 이전 코드의 핵심 기능을 다루기 시작하십시오. 또한 PM에게 추가 시간을 요청할 수 있습니다 =)