저장소 테스트에 대한 요구 사항으로도 단위 테스트에 대한 최소 백분율 코드 적용을 의무화해야한다면 무엇입니까?

당신이 당신의 대답에 어떻게 도달했는지 설명하십시오 (당신이 한 모든 것이 숫자를 고르면 나 혼자서 할 수 있었을 것입니다).

Alberto Savoia의이 글은 그 질문에 정확하게 답합니다 (그것에 아주 재미있는 방식으로)!

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

테스트 범위에 대한 Testivus

어느 날 아침, 프로그래머는 위대한 주인에게 물었습니다.

“일부 단위 테스트를 작성할 준비가되었습니다. 어떤 코드 범위를 목표로 삼아야합니까?”

위대한 주인이 대답했다.

"범위에 대해 걱정하지 말고 좋은 테스트를 작성하십시오."

프로그래머는 미소를 지으며 절을하고 떠났다.

...

그날 나중에 두 번째 프로그래머가 같은 질문을했습니다.

위대한 주인은 끓는 물 냄비를 가리키며 말했습니다.

“그 냄비에 몇 쌀의 쌀을 넣어야합니까?”

프로그래머가 당황스럽게 보며 대답했다.

“어떻게 말할 수 있습니까? 먹이를 줄 사람의 수, 배고픈 사람, 다른 음식을 제공하는 것, 사용할 수있는 쌀의 양 등에 달려 있습니다.”

“정확하게”라고 위대한 주인이 말했습니다.

두 번째 프로그래머는 미소를 지으며 절을하고 떠났다.

...

하루가 끝날 무렵, 세 번째 프로그래머가 와서 코드 범위에 대해 같은 질문을했습니다.

"80 % 이상!" 주인이 맹렬한 목소리로 대답하여 주먹을 탁자 위에 두드렸다.

세 번째 프로그래머는 미소를 지으며 절을하고 떠났다.

...

이 마지막 답변 후, 젊은 견습생이 위대한 주인에게 다가 갔다.

“훌륭한 주인님, 오늘 저는 코드 적용에 관한 동일한 질문에 세 가지 다른 답변을 들었습니다. 왜?"

위대한 주인이 의자에서 일어 섰습니다.

"나와 함께 신선한 차를 마시고 그것에 대해 이야기합시다."

그들이 뜨거운 녹차를 마시면서 컵을 채운 후 위대한 주인이 대답하기 시작했습니다.

“첫 번째 프로그래머는 새롭고 테스트를 시작했습니다. 지금은 코드가 많고 테스트가 없습니다. 그는 갈 길이 멀다. 현재 코드 범위에 초점을 맞추는 것은 우울하고 쓸모가 없습니다. 그는 테스트를 작성하고 실행하는 데 익숙해지는 것이 좋습니다. 그는 나중에 보험 적용에 대해 걱정할 수 있습니다.”

반면에 두 번째 프로그래머는 프로그래밍과 테스트에 모두 상당한 경험이 있습니다. 냄비에 쌀을 몇 개나 넣어야하는지 대답하면서 필요한 검사 량은 여러 가지 요인에 달려 있으며, 그녀는 내가하는 것보다 더 잘 알고 있다는 사실을 알게되었습니다. 결국 그녀의 코드입니다. . 하나의 단순하고 답이 없으며, 그녀는 진실을 다루고 그와 함께 일할만큼 똑똑합니다.”

젊은 견습생은 이렇게 말했습니다.“단순한 대답이 없다면 왜 세 번째 프로그래머에게 '80 % 이하로 대답하셨습니까? '

위대한 주인은 그의 배가 너무 강하게 크게 웃었고, 녹차보다 더 많이 마셨다는 증거가 위아래로 퍼졌다.

"세번째 프로그래머는 간단한 답변 만 원합니다 – 간단한 답변이없는 경우에도…

젊은 견습생과 어리석은 위대한 주인은 명상적인 침묵 속에서 차를 마셨다.

100 % 적용 범위를 목표로하는 경우 (모든 기능의 100 % 테스트 대신) Code Coverage는 잘못된 측정 기준입니다.

• 모든 라인을 한 번 치면 100 % 얻을 수 있습니다. 그러나 여전히 해당 행에 도달하는 특정 시퀀스 (논리 경로) 테스트를 놓칠 수 있습니다.
• 100 %를 얻을 수는 없지만 여전히 모든 80 % / freq 사용 코드 경로를 테스트했습니다. 당신이 넣은 모든 'throw ExceptionTypeX'또는 이와 유사한 방어 적 프로그래밍 가드를 테스트하는 테스트를받는 것은 '필수품'이 아닌 '좋은 것'입니다

따라서 자신이나 개발자가 자신의 코드를 통해 모든 경로를 철저히 준수해야합니다. 실용적이고 마법의 100 % 적용 범위를 쫓지 마십시오. 코드를 추가하면 90 % 이상의 적용 범위를 보너스로 받아야합니다. 코드 커버리지를 사용하여 놓친 코드 덩어리를 강조 표시하십시오 (TDD를 사용하는 경우에는 발생하지 않아야합니다.

코드 적용 범위는 크지 만 기능 적용 범위가 훨씬 좋습니다. 나는 내가 쓰는 모든 한 줄을 다루는 것을 믿지 않습니다. 그러나 나는 내가 제공하고자하는 모든 기능에 대해 100 % 테스트 범위를 작성한다고 믿습니다.

테스트에서 다루지 않은 코드가 있는지는 신경 쓰지 않지만 코드를 리팩터링하고 다른 동작을하게 될지 걱정합니다. 따라서 100 % 기능 범위가 유일한 목표입니다.

받아 들여진 대답은 좋은 지적입니다. 모든 프로젝트에 표준으로 적합한 단일 숫자는 없습니다. 그러한 표준이 필요없는 프로젝트가 있습니다. 제 생각에 수용 된 답변이 부족한 부분은 주어진 프로젝트에 대해 어떻게 결정을 내릴 수 있는지 설명하는 것입니다.

그렇게하겠습니다. 저는 테스트 엔지니어링 전문가가 아니며 더 많은 정보에 대한 답변을 보게되어 기쁩니다.

코드 범위 요구 사항을 설정하는시기

첫째, 왜 그러한 표준을 먼저 적용하고 싶습니까? 일반적으로 프로세스에 경험적 신뢰를 도입하려고 할 때. "경험적 확신"이란 ​​무엇입니까? 글쎄, 진짜 목표 정확성 . 대부분의 소프트웨어의 경우 모든 입력에서이를 알 수 없으므로 코드가 잘 테스트 되었다고 말합니다 . 이것은 더 잘 알려져 있지만 여전히 주관적인 표준입니다. 표준을 충족했는지 여부에 대해 항상 논의 할 수 있습니다. 이러한 토론은 유용하고 발생해야하지만 불확실성을 드러냅니다.

코드 적용 범위 는 객관적인 측정입니다. 일단 적용 범위 보고서를 보면 표준을 충족했는지 여부에 대한 모호성이 없습니다. 정확성을 증명합니까? 전혀 그렇지는 않지만 코드가 얼마나 잘 테스트되었는지와 분명한 관계가 있으며, 이는 정확성에 대한 신뢰를 높이는 가장 좋은 방법입니다. 코드 적용 범위는 우리가 관심을 갖는 측정 할 수없는 특성에 대한 측정 가능한 근사치입니다.

경험적 표준이 가치를 추가 할 수있는 몇 가지 구체적인 사례 :

• 이해 관계자 만족 많은 프로젝트의 경우, 소프트웨어 개발에 관여하지 않을 수있는 소프트웨어 품질에 관심이있는 다양한 행위자가 있습니다 (매니저, 기술 책임자 등). 우리가 정말로 필요로하는 시험 "은 설득력이 없습니다 : 그들은 전적으로 신뢰하거나 지속적으로 긴밀한 감독으로 검증해야합니다 (기술적 인 이해가 있다고 가정하더라도).
• 팀 행동을 정상화합니다. 이해 관계자 여러분, 여러 사람이 코드와 테스트를 작성하는 팀에서 일하는 경우 "잘 테스트 된"자격을 갖추기위한 모호성이 있습니다. 모든 동료가 어느 수준의 테스트가 충분한 지에 대한 동일한 아이디어를 가지고 있습니까? 아마 아닙니다. 이것을 어떻게 조정합니까? 모두 동의 할 수있는 측정 항목을 찾고 합리적인 근사값으로 수락하십시오. 예를 들어 리드가 주니어 개발자를 직접 감독하지 않는 대규모 팀에 특히 유용합니다. 신뢰 네트워크도 중요하지만 객관적인 측정이 없으면 모든 사람이 선의로 행동하더라도 그룹 행동이 일관성이 없어지기 쉽습니다.
• 자신을 정직하게 유지하십시오. 프로젝트의 유일한 개발자이자 유일한 이해 관계자 인 경우에도 소프트웨어의 특정 특성을 염두에 둘 수 있습니다. 소프트웨어의 성능에 대해 지속적으로 주관적인 평가를 수행하는 대신 (작업이 필요한) 코드 적용 범위를 합리적인 근사치로 사용하여 기계가이를 대신 할 수 있습니다.

사용할 측정 항목

코드 적용 범위는 단일 메트릭이 아닙니다. 적용 범위를 측정하는 방법에는 여러 가지가 있습니다. 표준을 설정할 수있는 것은 어느 표준을 만족시키기 위해 사용하고 있는지에 따라 다릅니다.

표준을 설정하는 데 사용할 수있는 두 가지 일반적인 측정 항목을 예로 사용하겠습니다.

• 명세서 범위 : 테스트 중에 실행 된 명세서의 몇 퍼센트입니까? 코드 의 실제 적용 범위 를 이해하는 데 유용합니다 . 실제로 작성한 코드의 양은 실제로 테스트 했습니까?
  • 이러한 종류의 적용 범위는 더 약한 정확성 주장을 지원하지만 달성하기도 더 쉽습니다. 방금 확인하기 위해 코드 커버리지를 사용하는 경우 있음 일들이 (그 이상 시험 품질의 지표로하지) 테스트를받을 다음 문 범위 아마 충분합니다.
• 분기 범위 : 분기 논리 (예 :) if가있는 경우 두 분기를 모두 평가 했습니까? 이렇게하면 코드 의 논리적 적용 범위 를 더 잘 이해할 수 있습니다. 코드에서 가능한 경로 중 몇 개를 테스트 했습니까?
  • 이러한 종류의 적용 범위는 프로그램이 포괄적 인 입력 세트에서 테스트되었음을 ​​훨씬 더 잘 나타내는 지표입니다. 정확성을 확신하기 위해 코드 적용 범위를 최상의 경험적 근사법으로 사용하는 경우 지점 적용 범위 또는 이와 유사한 기준에 따라 표준을 설정해야합니다.

다른 측정 항목이 있습니다 (줄 적용 범위는 명령문 적용 범위와 유사하지만 예를 들어, 여러 줄 명령문에 대해 다른 숫자 결과를 생성합니다. 조건부 적용 범위 및 경로 적용 범위는 분기 적용 범위와 유사하지만, 프로그램 실행이 발생할 수 있습니다.)

필요한 비율

마지막으로, 원래 질문으로 돌아갑니다. 코드 적용 표준을 설정하면 그 숫자는 무엇입니까?

이 시점에서 우리가 시작할 근사치에 대해 이야기하고 있음을 분명히 알기 때문에 우리가 선택한 숫자는 본질적으로 근사치입니다.

어떤 숫자를 선택할 수 있습니다 :

• 100 % . 모든 것이 테스트되었는지 확인하기 위해 이것을 선택할 수 있습니다. 이것은 테스트 품질에 대한 통찰력을 제공하지는 않지만 일부 품질 테스트가 모든 진술 (또는 지점 등)에 영향을 미쳤다는 것을 다시 말해줍니다. , 당신은 알고 코드의 어떤 부분 집합이 안된 것입니다.
  • 일부는 이것이 어리석은 것이라고 주장 할 수 있으며, 실제로 중요한 코드 부분 만 테스트해야합니다. 코드의 일부만 유지해야한다고 주장합니다. 테스트되지 않은 코드를 제거하여 코드 적용 범위를 향상시킬 수 있습니다.
• 99 % (또는 95 %, 90 년대의 다른 숫자) 100 % 와 비슷한 수준의 신뢰를 전달하고자 하지만 때때로 테스트하기 어려운 코너에 대해 걱정하지 않으려면 약간의 여유를 두십시오. 암호.
• 80 % . 이 숫자를 몇 번 사용하는 것을 보았으며 그것이 어디에서 왔는지 완전히 알지 못합니다. 나는 생각 이 80-20 규칙의 이상한 남용 수 있습니다; 일반적으로 여기서 의도는 대부분 의 코드가 테스트 되었음을 보여주기위한 것입니다 . (예, 51 %는 "가장 많음"이지만 80 %는 대부분의 사람들 이 가장 의미 하는 바를 더 잘 반영 합니다. 이는 "잘 테스트 된"이 우선 순위가 아닌 중간 사례에 적합합니다 ( 낮은 가치의 테스트에 노력을 낭비하고 싶지는 않지만 여전히 표준을 정하고 싶은 우선 순위로 충분합니다.

실제로 80 % 미만의 숫자는 보지 못했고 숫자를 설정할 사례를 상상하기가 어렵습니다. 이러한 표준의 역할은 정확성에 대한 신뢰를 높이는 것이며 80 % 미만의 숫자는 특히 자신감을 불러 일으키지는 않습니다. (예, 이것은 주관적이지만 다시 한 번 표준을 설정할 때 주관적인 선택을 한 다음 앞으로 객관적인 측정을 사용하는 것이 좋습니다.)

기타 노트

위의 내용은 정확성이 목표라고 가정합니다. 코드 범위는 정보 일뿐입니다. 다른 목표와 관련이있을 수 있습니다. 예를 들어, 유지 보수성에 관심이있는 경우 느슨한 결합에 관심이있을 수 있습니다. 느슨한 결합은 테스트 가능성에 의해 입증 될 수 있으며, 코드 커버리지에 의해 (특정 방식으로) 측정 될 수 있습니다. 따라서 코드 커버리지 표준은 "유지 보수성"의 품질을 근사화하기위한 경험적 기초를 제공합니다.

내가 가장 좋아하는 코드 범위는 별표로 100 %입니다. 별표는 특정 줄을 "카운트하지 않는"줄로 표시 할 수있는 도구를 선호하기 때문에 발생합니다. "계산 된"라인의 100 %를 커버하면 완료됩니다.

기본 프로세스는 다음과 같습니다.

1. 필자는 생각할 수있는 모든 기능과 엣지 사례 (일반적으로 문서에서 작업)를 연습하기 위해 테스트를 작성합니다.
2. 코드 커버리지 도구를 실행합니다
3. 다루지 않은 라인이나 경로 및 중요하지 않거나 도달 할 수없는 것으로 간주되는 (방어 적 프로그래밍으로 인해) 조사하지 않습니다.
4. 누락 된 줄을 다루기 위해 새로운 테스트를 작성하고 해당 사례를 언급하지 않은 경우 설명서를 개선합니다.

이렇게하면 나와 공동 작업자가 새 코드를 추가하거나 나중에 테스트를 변경하는 경우 중요한 내용을 놓쳤는 지 알려주는 밝은 선이 있습니다. 적용 범위가 100 % 아래로 떨어졌습니다. 그러나 다양한 테스트 우선 순위를 처리 할 수있는 유연성도 제공합니다.

공유하고 싶은 테스트 범위에 대한 또 다른 열망이 있습니다.

우리는 트위터를 통해 700 단위 테스트로 20 %의 코드 범위 만 가지고있는 거대한 프로젝트를 가지고 있습니다 .

Scott Hanselman 은 지혜로운 말로 대답했습니다 .

20 %가 맞습니까? 사용자가 가장 많이 이용하는 코드를 나타내는 것이 20 %입니까? 테스트를 50 개 더 추가하고 2 % 만 추가 할 수 있습니다.

다시, 그것은 코드 범위 답변 에 대한 내 Testivus 로 돌아갑니다 . 냄비에 밥을 얼마나 넣어야합니까? 때에 따라 다르지.

단위 테스트가 처음부터 개발을 주도한 잘 설계된 시스템의 경우 85 %가 매우 적습니다. 테스트 가능하도록 설계된 소규모 수업은 그보다 더 잘 다루기가 어렵지 않아야합니다.

이 질문을 다음과 같이 무시하는 것은 쉽습니다.

• 해당 라인은 테스트 된 로직과 같지 않으며 백분율로 너무 많이 읽지 않아야합니다.

사실이지만 코드 범위에 대해 몇 가지 중요한 사항이 있습니다. 내 경험상이 지표는 올바르게 사용될 때 실제로 매우 유용합니다. 나는 모든 시스템을 보지 못했으며 실제 범위를 추가하는 코드 범위 분석을보기 어려운 곳에 많은 시스템이 있다고 확신합니다. 코드는 다르게 보일 수 있으며 사용 가능한 테스트 프레임 워크의 범위는 다를 수 있습니다.

또한, 나의 추론은 주로 매우 짧은 테스트 피드백 루프에 관한 것입니다. 가장 짧은 피드백 루프를 개발하는 제품의 경우 클래스 테스트에서 프로세스 간 신호에 이르는 모든 것을 다루는 매우 유연합니다. 전달 가능한 하위 제품을 테스트하는 데 일반적으로 5 분이 걸리며 이러한 짧은 피드백 루프의 경우 실제로 테스트 결과 (특히 여기에서보고있는 코드 범위 메트릭)를 사용하여 저장소에서 커밋을 거부하거나 수락 할 수 있습니다.

코드 커버리지 메트릭을 사용할 때 반드시 충족되어야하는 고정 된 (임의의) 백분율을 가져서는 안됩니다. 이렇게한다고해서 코드 커버리지 분석의 실질적인 이점은 제 생각에는 없습니다. 대신 다음 측정 항목을 정의하십시오.

• LWM (Low Water Mark), 테스트중인 시스템에서 가장 적은 수의 노출 된 라인
• 테스트중인 시스템에서 가장 높은 코드 적용률 인 High Water Mark (HWM)

새로운 코드는 LWM보다 높지 않고 HWM보다 낮은 경우에만 추가 할 수 있습니다. 즉, 코드 적용 범위 를 줄일 수 없으며 새로운 코드를 적용해야합니다. 내가 말해야한다고 말해야하는 것을 주목하라 (아래 설명).

그러나 이것이 더 이상 사용하지 않는 오래된 잘 테스트 된 쓰레기를 치울 수 없다는 것을 의미하지 않습니까? 그렇기 때문에 이런 것들에 대해 실용적이되어야합니다. 규칙을 위반해야하는 상황이 있지만 일반적인 일상적인 통합을 위해서는 이러한 메트릭스가 매우 유용하다는 경험이 있습니다. 다음 두 가지 의미를 내포합니다.

• 테스트 가능한 코드가 승격됩니다. 새 코드를 추가 할 때는 코드를 테스트 할 수 있도록 노력해야합니다. 테스트 케이스로 코드를 모두 처리해야하기 때문입니다. 테스트 가능한 코드는 일반적으로 좋은 것입니다.

• 레거시 코드에 대한 테스트 범위는 시간이 지남에 따라 증가하고 있습니다. 새 코드를 추가하고 테스트 사례로 처리 할 수없는 경우 LWM 규칙을 피하기 위해 일부 기존 코드를 다루려고 시도 할 수 있습니다. 때때로 필요한 부정 행위는 레거시 코드의 적용 범위가 시간이 지남에 따라 증가 할 것이라는 긍정적 인 부작용을 제공하여 실제로 이러한 규칙을 엄격하게 시행하는 것처럼 보입니다.

그리고 피드백 루프가 너무 길면 통합 프로세스에서 이와 같은 것을 설정하는 것이 실용적이지 않을 수 있습니다.

코드 커버리지 메트릭의 두 가지 일반적인 이점에 대해서도 언급하고 싶습니다.

• 코드 적용 범위 분석은 정적 코드 (예 : Lint)와 달리 동적 코드 분석의 일부입니다. 동적 코드 분석 중에 발견 된 문제점 (purify 제품군, http://www-03.ibm.com/software/products/en/rational-purify-family 와 같은 도구 )은 초기화되지 않은 메모리 읽기 (UMR)와 같은 문제입니다. 메모리 누수 등. 이러한 문제는 코드가 실행 된 테스트 케이스에 의해 커버되는 경우에만 발견 될 수 있습니다 . 테스트 사례에서 다루기가 가장 어려운 코드는 일반적으로 시스템의 비정상 사례이지만 시스템이 정상적으로 실패하기를 원하면 (예 : 충돌 대신 오류 추적) 비정상 사례를 다루는 데 약간의 노력을 기울일 수 있습니다. 동적 코드 분석에서도 마찬가지입니다. 약간의 불운으로 UMR은 segfault 또는 더 나쁜 결과를 초래할 수 있습니다.

• 사람들은 새로운 코드를 100 % 유지하는 데 자부심을 갖고 다른 구현 문제와 비슷한 열정으로 테스트 문제에 대해 토론합니다. 이 기능을보다 테스트 가능한 방식으로 작성하려면 어떻게해야합니까? 이 비정상적인 사건 등을 다루려고 어떻게 할 것입니까?

그리고 완전성에 대한 부정적인.

• 관련 개발자가 많은 대규모 프로젝트에서 모든 사람이 테스트 천재가 될 수는 없습니다. 어떤 사람들은 코드 커버리지 메트릭을 코드가 테스트되었다는 증거로 사용하는 경향 이 있으며이 질문에 대한 다른 많은 답변에서 언급했듯이 이것은 사실 과 거리가 멀습니다 . 제대로 사용하면 좋은 이점을 줄 수있는 하나의 메트릭이지만 잘못 사용하면 실제로 테스트가 잘못 될 수 있습니다. 위에서 언급 한 매우 유용한 부작용 외에도 테스트 대상 시스템은 일부 입력 데이터에 대해 해당 라인에 도달 할 수 있으며 중단 또는 중단없이 실행할 수 있음을 보여줍니다.

이것이 완벽한 세계라면 코드의 100 %가 단위 테스트에 의해 커버 될 것입니다. 그러나 이것은 완벽한 세상이 아니기 때문에 당신이 원하는 시간의 문제입니다. 결과적으로 특정 비율에 중점을 두지 말고 중요한 영역에 더 집중하는 것이 좋습니다. 코드가 잘 작성된 경우 (또는 적어도 합리적인 팩시밀리) API가 다른 코드에 노출되는 몇 가지 핵심 사항이 있습니다.

이러한 API에 대한 테스트 노력에 집중하십시오. API가 1) 잘 문서화되어 있고 2) 문서와 일치하는 테스트 사례가 작성되어 있는지 확인하십시오. 예상 결과가 문서와 일치하지 않으면 코드, 설명서 또는 테스트 사례에 버그가있는 것입니다. 모두 수의사에게 좋습니다.

행운을 빕니다!

많은 상점은 테스트를 중요하게 생각하지 않으므로 적어도 0 이상인 경우 가치에 대한 인식이 있습니다. 따라서 0이 아닌 것은 많은 수가 0이므로 나쁘지 않습니다.

.Net 세계에서 사람들은 종종 80 %를 합리적으로 인용합니다. 그러나 그들은 솔루션 수준에서 이것을 말합니다. 프로젝트 수준에서 측정하는 것을 선호합니다 .Selenium 등을 사용하는 경우 30 %가 UI 프로젝트에 적합하거나 수동 테스트, 데이터 계층 프로젝트에 대해 20 %는 괜찮을 수 있지만 95 % 이상은 비즈니스에 매우 적합 할 수 있습니다 완전히 필요하지 않은 경우 규칙 계층. 따라서 전체 적용 범위는 60 % 일 수 있지만 중요한 비즈니스 논리는 훨씬 더 높을 수 있습니다.

나는 또한 이것을 들었다 : 100 %를 열망하고 당신은 80 %를 칠 것이다; 80 %를 목표로하면 40 %에 도달합니다.

결론 : 80:20 규칙을 적용하고 앱의 버그 수를 안내하십시오.

코드 범위는 또 다른 지표입니다. 그 자체로 매우 오해의 소지가 있습니다 ( www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated 참조 ). 따라서 목표는 100 % 코드 적용 범위를 달성하는 것이 아니라 응용 프로그램의 모든 관련 시나리오를 테스트하는 것입니다.

체크인 기준으로 85 %가 좋은 출발점이 될 것입니다.

테스트 대상 서브 시스템 / 컴포넌트의 중요도에 따라 운송 기준으로 다양한 고급 바를 선택했을 것입니다.

나는 cobertura를 사용하며, 백분율에 관계없이 cobertura-check 작업의 값을 최신 상태로 유지하는 것이 좋습니다. 최소한 totallinerate 및 totalbranchrate를 현재 적용 범위 바로 아래로 올리 되이 값을 낮추지 마십시오 . 또한 Ant 빌드 실패 특성을이 태스크와 연관 시키십시오. 적용 범위가 부족하여 빌드가 실패하면 다른 사람이 추가 한 코드는 알고 있지만 테스트하지 않은 것입니다. 예:

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

내 코드가 충분히 단위 테스트되지 않았다고 생각하고 다음에 무엇을 테스트해야할지 잘 모르겠 으면 다음 테스트 대상을 결정하는 데 도움이됩니다.

단위 테스트에서 적용 범위를 늘리면이 단위 테스트의 가치가 있다는 것을 알고 있습니다.

이것은 적용되지 않는 코드, 50 % 적용 또는 97 % 적용되는 코드에 적용됩니다.

자동 수락 테스트, 다른 통합 테스트 및 단위 테스트의 조합을 사용하는 BDD를 선호합니다. 나에게 대한 질문은 자동화 된 테스트 스위트의 목표 범위가 무엇인지에 대한 것입니다.

그 외에도 대답은 방법론, 언어 및 테스트 및 적용 범위 도구에 따라 다릅니다. Ruby 또는 Python에서 TDD를 수행 할 때는 100 % 적용 범위를 유지하는 것이 어렵지 않으며 그렇게하는 것이 좋습니다. 90 % 적용 범위보다 100 % 적용 범위를 관리하는 것이 훨씬 쉽습니다. 즉, 커버리지 갭을 작성하는 것이 훨씬 쉽고 (TDD를 잘 수행 할 때 커버리지 갭이 드물고 일반적으로 시간 가치가있는 경우) 도달하지 않은 커버리지 갭 목록을 관리하는 것보다 훨씬 쉽습니다. 발견되지 않은 코드의 지속적인 배경으로 인한 회귀

답은 프로젝트 히스토리에 따라 다릅니다. 위의 방법은 처음부터 그런 방식으로 관리되는 프로젝트에서 실용적이라는 것을 알았습니다. 나는 큰 레거시 프로젝트의 적용 범위를 크게 개선했으며 그럴만 한 가치가 있었지만 테스트되지 않은 오래된 코드는 올바르게 이해하기에 충분하지 않기 때문에 모든 적용 범위 간격을 채우는 것이 실용적이지 못했습니다. 빨리.

괜찮은 시간 동안 단위 테스트를 해본 적이 있다면 95 % 이상에 도달 할 이유가 없습니다. 그러나 최소한 테스트를 처음 할 때도 항상 80 %로 작업했습니다.

이 숫자는 프로젝트에서 작성된 코드 (프레임 워크, 플러그인 등 제외) 만 포함해야하며 외부 코드 호출로 작성된 코드로 구성된 특정 클래스를 제외 할 수도 있습니다. 이런 종류의 통화는 조롱 / 스터 빙해야합니다.

일반적으로, 내가 읽은 여러 엔지니어링 우수 모범 사례 논문에서 단위 테스트의 새 코드에 대해 80 %가 최고의 수익을 낼 수있는 지점입니다. CC %를 초과하면 노력의 양에 대한 결함의 양이 줄어 듭니다. 이것은 많은 주요 회사에서 사용하는 모범 사례입니다.

불행히도, 이러한 결과의 대부분은 회사 내부에 있으므로, 내가 지적 할 수있는 공개 문헌은 없습니다.

코드 범위는 훌륭하지만 코드를 통해 얻을 수있는 이점이 코드 비용 / 노력을 능가하는 경우에만 가능합니다.

우리는 한동안 80 %의 표준으로 작업 해 왔지만,이를 버리고 결정에 더 중점을 두었습니다. 복잡한 비즈니스 로직 등에 집중

이 결정은 코드 적용 범위를 추적하고 기존 단위 테스트를 유지하는 데 소요되는 시간이 늘어남에 따라 결정되었습니다. 우리는 코드 범위에서 얻는 이점이 코드를 달성하기 위해 노력했던 것보다 적다고 생각했습니다.

짧은 대답 : 60-80 %

긴 대답 : 나는 그것이 프로젝트의 본질에 전적으로 달려 있다고 생각합니다. 나는 일반적으로 모든 실용적인 부분을 단위 테스트하여 프로젝트를 시작합니다. 프로젝트의 첫 번째 "릴리스"를 수행하면 수행중인 프로그래밍 유형에 따라 기본 비율이 상당히 높아야합니다. 이 시점에서 최소 코드 적용 범위를 "시행"할 수 있습니다.

Crap4j를 확인하십시오 . 스트레이트 코드 범위보다 약간 더 정교한 접근 방식입니다. 코드 커버리지 측정과 복잡성 측정을 결합한 다음 현재 테스트되지 않은 복잡한 코드를 보여줍니다.

이 수수께끼에 대한 나의 대답은 테스트 할 수있는 코드의 100 % 라인 적용 범위와 테스트 할 수없는 코드의 0 % 라인 적용 범위를 갖는 것입니다.

파이썬에서 현재 .py 모듈을 app1 /과 app2 /의 두 폴더로 나누는 것입니다. 단위 테스트를 실행할 때 두 폴더의 적용 범위를 계산하고 app1이 100 % 적용 범위인지 시각적으로 확인하십시오 ( 언젠가 자동화 해야 함 ). app2의 범위는 0 %입니다.

이 숫자가 표준과 다름을 알면 적용 범위가 표준을 준수하도록 조사하고 코드 디자인을 변경합니다.

이것은 라이브러리 코드의 100 % 라인 적용 범위를 달성 할 것을 권장 할 수 있음을 의미합니다.

또한 때때로 app2 /를 검토하여 코드를 테스트 할 수 있는지 확인하고 app1 /으로 코드를 옮길 수 있는지 확인합니다.

이제는 프로젝트의 규모에 따라 크게 다를 수 있기 때문에 집계 범위에 대해 걱정하지 않지만 일반적으로 70 %에서 90 % 이상을 보았습니다.

파이썬을 사용하면 적용 범위를 측정하는 동안 자동으로 앱을 실행할 수있는 연기 테스트를 고안 할 수 있어야하며 연기 테스트와 단위 테스트 수치를 결합하면 100 %의 합병을 얻을 수 있습니다.

다른 관점에서 적용 범위보기 : 명확한 제어 흐름을 갖춘 잘 작성된 코드는 다루기 가장 쉽고 읽기 쉽고 가장 버그가 적은 코드입니다. 명확성과 적용 성을 염두에두고 코드를 작성하고 코드와 병행하여 단위 테스트를 작성하면 최상의 결과를 얻을 수 있습니다.

제 생각에는 "얼마나 많은 시간이 있느냐에 달려 있습니다"라고 대답합니다. 나는 100 %를 달성하려고 노력하지만 시간이 없어도 소란을 피우지 않습니다.

단위 테스트를 작성할 때 생산 코드를 개발할 때 착용하는 모자와 다른 모자를 착용합니다. 테스트 된 코드가 무엇을 주장하고 그것을 깨뜨릴 수있는 상황에 대해 생각합니다.

나는 보통 다음 기준 또는 규칙을 따릅니다.

1. 단위 테스트는 내 코드의 예상되는 동작에 대한 문서 형식이어야합니다. 특정 입력이 주어진 예상 출력과 클라이언트가 잡기를 원할 수있는 예외가 발생했습니다 (내 코드 사용자는 무엇을 알아야합니까?)

2. 단위 테스트를 통해 아직 생각하지 못한 조건을 발견 할 수 있습니다. (코드를 안정적이고 강력하게 만드는 방법은 무엇입니까?)

이 두 규칙이 100 % 적용 범위를 생성하지 않으면 적용됩니다. 그러나 시간이 있으면 발견되지 않은 블록과 라인을 분석하고 단위 테스트가없는 테스트 사례가 있는지 또는 불필요한 코드를 제거하기 위해 코드를 리팩터링해야하는지 결정합니다.

응용 프로그램에 따라 크게 다릅니다. 예를 들어 일부 응용 프로그램은 단위 테스트를 할 수없는 GUI 코드로 구성됩니다.

나는 그런 B / W 규칙이있을 수 있다고 생각하지 않습니다.
중요한 세부 사항에 특히주의하면서 코드를 검토해야합니다.
그러나 테스트되지 않은 경우 버그가 있습니다!

코드의 중요도에 따라 75 % -85 %가 좋은 규칙입니다. 배송 코드는 하우스 유틸리티 등보다 철저하게 테스트해야합니다.

이는 현재 애플리케이션 개발 라이프 사이클의 단계에 따라 달라집니다.

한동안 개발을 해왔고 이미 구현 된 코드가 많고 코드 커버리지에 대해 생각해야한다는 것을 깨닫고 있다면 현재 커버리지 (있는 경우)를 확인한 다음 해당 기준을 사용하여 각 스프린트 (또는 스프린트 기간의 평균 상승)마다 마일스톤을 설정합니다. 즉, 최종 사용자 가치를 계속 제공하면서 코드 부채를 감당해야합니다 (최소한 제 경험상 테스트를 늘린 경우 최종 사용자는 1 비트를 신경 쓰지 않습니다) 새로운 기능이 표시되지 않는 경우 적용 범위).

귀하의 도메인에 따라 95 %를 불합리한 것은 아니지만 평균적으로 85 %에서 90 %의 평균 사례를 보겠다고 말해야합니다.

올바른 코드 적용 범위의 가장 좋은 증상은 단위 테스트를 수정하는 데 도움이되는 구체적인 문제의 양이 생성 한 단위 테스트 코드의 크기와 합리적으로 일치한다는 것입니다.

가장 중요한 것은 시간이 지남에 따라 적용 범위 추세가 무엇인지 알고 추세 변화의 이유를 이해하는 것입니다. 추세의 변화를 좋거나 나쁘게 보는 것은 그 이유에 대한 분석에 달려 있습니다.

며칠 전까지 80 % 이상을 목표로 삼았지만 많은 생성 코드를 사용한 후에는 % age를 신경 쓰지 않고 검토자가 필요한 적용 범위에 대해 전화를 걸도록합니다.

Testivus 게시에서 답변 컨텍스트가 두 번째 프로그래머 여야한다고 생각합니다. 실용적인 관점에서 이것을 말 했으므로 우리는 노력할 매개 변수 / 목표가 필요합니다. 아키텍처, 기능 (사용자 스토리)이있는 코드를 분석 한 다음 여러 가지를 찾아서 애자일 프로세스에서 "테스트"할 수 있다고 생각합니다. 통신 분야에서의 경험을 바탕으로 60 %가 확인하기에 좋은 가치라고 말합니다.