단위 테스트에 얼마나 많은 시간을 소비합니까?

내가 근무했던 회사에서 경영진은 단위 테스트를 통한 코드 적용 범위가 99 % 이상이어야한다고 주장했습니다. 이로 인해 코드보다 더 많은 테스트가 작성되었습니다. 구현하는 데 하루가 걸리는 단일 클래스에 대한 테스트를 작성하는 데 문자 그대로 3 일이 걸렸습니다.

그러나 결과적으로 TDD, 테스트 도구, 실습 등에 대해 많이 배웠습니다.

나중에 근무했던 회사에서는 단위 테스트가 알려지지 않았습니다. 누군가 전에 들었을 수도 있습니다. 나는 그것들을 단위 테스트의 개념에 소개하려고 노력했지만 효과는 없었습니다.

지금과 같은 자영업자, 궁금 - 시간이 얼마나 정말 단위 테스트에 지출 할 필요가? 주로 iPhone / Android 개발자인데 코드의 어느 부분을 테스트에서 다루어야합니까?

필요한 단위 테스트 양은 몇 가지 요소에 따라 다릅니다.

• 제품 크기 (프로젝트가 클수록 적어도 일부 단위 테스트를 포함해야 할 필요성)
• 필요한 품질 수준 (가능한 한 빨리 나가야하는 소프트웨어를 신속하게 정리하고 일부 사소한 버그를 수용 할 수 있으면 단위 테스트와 같은 일부 테스트를 건너 뛰어야 할 수도 있습니다)
• 제품 유형 (UI는 단위 테스트가 가능하지만 때로는 프로젝트의 무거운 GUI 섹션에서 단위 테스트를 건너 뛰고 대신 수동으로 테스트하는 것이 더 쉽습니다)
• 코딩 능력 / 이력

제품 그룹에서는 단위 테스트에서 50-70 %의 코드 범위를, 단위 테스트 및 테스트 자동화에서 90 % 이상의 범위를 목표로합니다. 단위 테스트 작성에 소요되는 일반적인 시간은 3-4 일의 헤드 다운 코딩이 필요한 모든 기능에 대해 약 1 일입니다. 그러나 그것은 많은 요인에 따라 달라질 수 있습니다.

99 % 코드 범위가 훌륭합니다. 단위 테스트는 훌륭합니다. 그러나 단위 테스트만으로 99 % 코드 적용 범위는? 단위 테스트 만으로도 많은 정보를 얻을 수 있다고 믿기가 어렵 습니다.

구현하는 데 하루가 걸리는 클래스에 대한 테스트를 작성하는 데 3 일을 소비 한 경우. 왜 이렇게 오래 걸렸거나 코드를 공유하는 이유에 대해 자세히 설명하지 않았습니다. 추측에서, 당신은 실제로 클래스에 대한 실제 단위 테스트를 작성하는 것이 아니라 실제로 테스트 자동화를 작성하고 있다고 추측합니다 . 그리고 두 가지 유형의 테스트 간의 차이점을 인식하는 한 실제로 아무런 문제가 없습니다.

그러나 3 일간의 시험 작문은 단일 수업만을위한 것이라고합니다. 아마도 클래스 자체는 단위 테스트를 위해 설계되지 않았을 것입니다. 클래스가 UI를 구현합니까? 네트워킹? 파일 I / O? 그렇다면 런타임과 상호 작용하는 비즈니스 로직보다 Java 런타임을 테스트하기 위해 더 많은 코드를 작성했을 수 있습니다.

TDD는 인터페이스와 인터페이스에 대한 의존성을 고려합니다. 단일 기능에 대해 UI, 네트워킹 및 파일 / IO를 구현하는 단일 클래스는 네트워킹, 파일 / IO 및 UI를 모델 뷰어 컨트롤러 디자인으로 분류 한 여러 클래스로 나눌 수 있습니다. 그런 다음 종속성에 대한 간단한 모의 객체를 사용하여 각각에 대해 적절한 테스트를 구현할 수 있습니다. 물론이 모든 것이 더 많은 시간이 걸립니다. 따라서 코딩하는 데 1 일, 테스트를 작성하는 데 3 일이 아닌이 유형의 디자인에는 3 일의 코딩과 1 일의 쓰기 테스트가 필요할 수 있습니다. 그러나 코드의 유지 관리 및 재사용 성이 훨씬 향상됩니다.

단위 테스트는 유지 보수시 보수를받습니다. 장기 사용 신청을 할 계획이라면 지금 생각보다 유지 관리에 더 많은 시간을 할애 할 것입니다 (아직 시도하지 않은 경우 성공적인 프로젝트가 얼마나 오래 살 수 있는지에 놀랄 것입니다)

원하는 것은 실수로 기능을 변경 하면 테스트가 중단되어 가능한 한 빨리 찾을 수 있다는 것입니다. 고객은 기능이 예기치 않게 변경 될 때 매우 싫어합니다.

TDD를 수행하는 경우 코드와 동시에 테스트를 작성하여 몇 분 (또는 그 이하)마다 전환합니다. 테스트에 별도의 시간이 소요되지는 않습니다. TDD를 사용하면 테스트 범위가 확실하다는 것을 훨씬 쉽게 알 수 있습니다.

사실 후에 단위 테스트를 수행하는 경우 변경으로 인해 코드가 손상되었는지 알려주는 테스트를 작성해야합니다. 여기서는 커버리지 메트릭에 의존하지 않지만 공용 인터페이스에 대한 사용 사례 및 매개 변수를 기반으로합니다. 이것은 궁극적으로 당신의 좋은 취향과 경험에 근거 할 것입니다.

테스트에 시간을 소비하지 않으면 라이브 코드에서 디버깅하는 데 더 많은 시간이 소요됩니다.
따라서 테스트하는 데 필요한 시간을 모두 (또는 코드의 99 %) 처리하십시오.

다른 사람들이 이미 언급했듯이 소프트웨어 유형에 크게 의존합니다. 언급 한 3 : 1 테스트 / 개발 시간 비율은 일반 프로젝트에 비해 너무 많을 수도 있지만 미션 크리티컬 앱에는 완벽하게 맞을 수도 있고 생명에 중요한 시스템에는 너무 작을 수도 있습니다.

99 % 이상의 단위 테스트 적용 범위는 평균 앱의 경우 예상하기에는 너무 많지만 생명에 중요한 프로젝트에는 너무 적습니다.

필자의 경험에 따르면 프로덕션 코드의 상당 부분이 오류 처리 코드라는 점을 고려하면 80-90 %의 범위만으로도 대부분의 앱에 충분하며 이는 프로덕션 코드와 단위 테스트를 작성하는 데 거의 같은 시간이 소요될 수 있습니다. (따라서, 하나가 TDD 방식으로 열심히 일한다면, 둘은 실질적으로 하나의 작업이되기 위해 완전히 얽혀 있기 때문에 실제 비율 만 추측 할 수 있습니다.)