단위 테스트에 대한 합리적인 코드 적용 범위는 얼마이며 그 이유는 무엇입니까?[닫은]

https://stackoverflow.com/questions/90002

01-07-2019
|

문제

저장소에 커밋하기 위한 요구 사항으로 단위 테스트에 대한 최소 비율의 코드 적용 범위를 요구한다면 그것은 무엇입니까?

어떻게 답을 얻었는지 설명해주세요. (만약 당신이 숫자만 골랐다면 저 혼자 다 할 수 있었을 테니까요.)

해결책

Alberto Savoia의 이 산문은 그 질문에 정확하게 답합니다(매우 재미있는 방식으로!).

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

테스트 범위에 대한 Testivus

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

“몇 가지 단위 테스트를 작성할 준비가 되었습니다.어떤 코드 적용 범위를 목표로해야합니까?”

위대한 스승은 이렇게 대답했습니다.

"커버리지에 대해 걱정하지 말고 좋은 테스트를 작성하세요."

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

...

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

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

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

당황스러워 보이는 프로그래머는 다음과 같이 대답했다.

“내가 어떻게 당신에게 말할 수 있겠습니까?그것은 얼마나 많은 사람들에게 먹이를 주어야하는지, 얼마나 배가 고프고, 다른 음식을 제공하는 다른 음식, 쌀을 얼마나 많이 구할 수 있는지 등에 달려 있습니다.”

“정확히 그렇죠.” 위대한 스승이 말했습니다.

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

...

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

"80 %, 그 이하!" 주먹을 탁자에 두드리면서 마스터에게 엄격한 목소리로 대답했습니다.

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

...

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

“Great Master, 오늘 나는 당신이 세 가지 답변으로 코드 커버리지에 대해 같은 질문에 대답했다고 들었습니다.왜?"

그레이트 마스터는 그의 의자에서 일어 섰다.

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

컵을 흡연 핫 녹차로 채운 후 그레이트 마스터는 대답하기 시작했습니다.

“첫 번째 프로그래머는 신입이고 이제 막 테스트를 시작했습니다.지금 그는 코드가 많고 테스트가 없습니다.그는 갈 길이 멀다.현재 코드 커버리지에 중점을두면 우울하고 쓸모가 없습니다.그는 테스트를 작성하고 실행하는 데 익숙해지는 것이 좋습니다.그는 나중에 적용 범위에 대해 걱정할 수 있습니다.”

“반면 두 번째 프로그래머는 프로그래밍 및 테스트에서 경험입니다.냄비에 얼마나 많은 쌀을 넣어야하는지 물었을 때, 나는 그녀가 필요한 테스트의 양이 여러 요인에 달려 있다는 것을 깨닫도록 도와 주었고, 그녀는 내가하는 것보다 그 요소를 더 잘 알고 있습니다 - 결국 그녀의 코드입니다. .단일, 단순한 대답은 없으며, 그녀는 진실을 다루고 그로 일할만큼 똑똑합니다.”

젊은 견습생은“나는 단일 대답이 없다면 왜 세 번째 프로그래머에 '80 %'라고 대답 했습니까?”라고 말했습니다.

그레이트 마스터는 너무 세게 웃고 큰 소리로 그의 배가 크고 녹차보다 더 많이 마셨다는 증거가 위아래로 퍼졌습니다.

"세 번째 프로그래머는 간단한 답변 만 원합니다. 간단한 답변이 없더라도… 어쨌든 그들을 따르지 않습니다."

젊은 견습생과 회색의 위대한 주인은 명상적인 침묵으로 차를 마시 셨습니다.

다른 팁

코드 적용 범위는 모든 기능을 100% 테스트하는 대신 100% 적용 범위가 목표인 경우 오해의 소지가 있는 측정 기준입니다.

모든 라인을 한 번만 치면 100%를 얻을 수 있습니다.그러나 해당 행이 적중되는 특정 시퀀스(논리 경로) 테스트를 놓칠 수도 있습니다.
100%를 얻을 수는 없었지만 여전히 80%/주파수로 사용된 코드 경로를 모두 테스트했습니다.모든 'throw ExceptionTypeX' 또는 귀하가 설치한 유사한 방어 프로그래밍 가드를 테스트하는 테스트를 갖는 것은 '필수'가 아니라 '있으면 좋은' 것입니다.

따라서 자신이나 개발자가 철저하고 코드의 모든 경로를 다룰 것이라고 믿으십시오.실용적이게 행동하고 마법같은 100% 적용 범위를 추구하지 마십시오.코드를 TDD하면 보너스로 90% 이상의 커버리지를 얻을 수 있습니다.코드 적용 범위를 사용하여 놓친 코드 덩어리를 강조 표시합니다. (TDD인 경우에는 발생하지 않습니다.)왜냐하면 테스트 통과를 위해서만 코드를 작성하기 때문입니다.파트너 테스트 없이는 코드가 존재할 수 없습니다.)

코드 적용 범위는 훌륭하지만 기능 적용 범위는 훨씬 더 좋습니다.나는 내가 쓴 모든 한 줄을 다룰 수 없다고 믿습니다.그러나 나는 내가 제공하고 싶은 모든 기능에 대해 100% 테스트 범위를 작성한다고 믿습니다. (심지어 내가 직접 제공하고 회의 중에 논의되지 않은 추가 멋진 기능에 대해서도)

테스트에서 다루지 않은 코드가 있는지는 상관하지 않지만, 코드를 리팩토링하여 결국 다른 동작을 하게 되는지 여부는 신경쓰겠습니다.따라서 100% 기능 적용이 나의 유일한 목표입니다.

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

나는 그렇게 하려고 노력할 것이다.저는 테스트 엔지니어링 전문가가 아니므로 더 많은 정보를 바탕으로 답변을 듣고 싶습니다.

코드 적용 범위 요구 사항을 설정하는 경우

첫째, 애초에 왜 그러한 기준을 부과하려고 합니까?일반적으로 공정에 경험적 신뢰도를 부여하려는 경우입니다."경험적 신뢰"란 무엇을 의미합니까?자, 진짜 목표는 단정.대부분의 소프트웨어에서는 모든 입력에 대해 이를 알 수 없으므로 코드는 다음과 같습니다. 잘 테스트된.이는 더 잘 알려져 있지만 여전히 주관적인 표준입니다.당신이 그것을 만났는지 여부는 항상 토론의 여지가 있습니다.이러한 논쟁은 유용하고 일어나야 하지만, 불확실성을 노출하기도 합니다.

코드 적용 범위 객관적인 측정입니다.적용 범위 보고서를 보면 표준이 충족되었는지 여부에 대한 모호함이 없습니다.그것이 정확성을 증명하는가?전혀 그렇지는 않지만, 이는 코드가 얼마나 잘 테스트되었는지와 명확한 관계가 있으며, 이는 결과적으로 코드의 정확성에 대한 확신을 높이는 최선의 방법입니다.코드 적용 범위는 우리가 관심을 갖는 헤아릴 수 없는 품질의 측정 가능한 근사치입니다.

경험적 표준을 통해 가치를 더할 수 있는 몇 가지 구체적인 사례는 다음과 같습니다.

이해관계자를 만족시키기 위해. 많은 프로젝트에는 소프트웨어 품질에 관심이 있지만 일상적인 소프트웨어 개발에는 참여하지 않을 수도 있는 다양한 행위자(관리자, 기술 책임자 등)가 있습니다. 우리에게 정말 필요한 테스트"라는 말은 설득력이 없습니다.전적으로 신뢰하거나 지속적인 면밀한 감독을 통해 검증해야 합니다(기술적으로 이해하고 있다고 가정). 측정 가능한 표준을 제공하고 실제 목표에 합리적으로 접근하는 방법을 설명하는 것이 더 좋습니다.
팀 행동을 정상화합니다. 이해 관계자는 제쳐두고 여러 사람이 코드와 테스트를 작성하는 팀에서 일하고 있다면 "잘 테스트를 거친"자격이있는 것에 대한 모호성의 여지가 있습니다. 모든 동료들이 어떤 수준의 테스트가 충분한 지에 대해 동일한 아이디어를 가지고 있습니까?아마도 그렇지 않을 것입니다.이걸 어떻게 조화시키나요?모두가 동의할 수 있는 측정항목을 찾고 이를 합리적인 근사치로 받아들입니다.이는 예를 들어 리드가 주니어 개발자를 직접 감독할 수 없는 대규모 팀에서 특히(그러나 배타적이지는 않음) 유용합니다.신뢰 네트워크도 중요하지만 객관적인 측정이 없으면 모든 사람이 선의로 행동하더라도 그룹 행동이 일관되지 않게 되기 쉽습니다.
자신을 정직하게 유지하기 위해. 귀하가 프로젝트의 유일한 개발자이자 유일한 이해관계자인 경우에도 소프트웨어에 대해 염두에 두고 있는 특정 특성이 있을 수 있습니다.소프트웨어가 얼마나 잘 테스트되었는지(작업이 필요함)에 대해 지속적으로 주관적인 평가를 하는 대신, 코드 적용 범위를 합리적인 근사치로 사용하고 기계가 이를 측정하도록 할 수 있습니다.

사용할 측정항목

코드 적용 범위는 단일 측정항목이 아닙니다.적용 범위를 측정하는 방법에는 여러 가지가 있습니다.어떤 표준을 설정할지는 해당 표준을 사용하여 만족시키는 대상에 따라 다릅니다.

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

명세서 적용 범위:테스트 중에 몇 퍼센트의 명령문이 실행되었습니까?감을 잡는 데 유용하다. 물리적 범위 귀하의 코드 중:내가 작성한 코드 중 실제로 테스트한 코드는 얼마나 됩니까?
- 이러한 종류의 적용 범위는 약한 정확성 주장을 뒷받침하지만 달성하기가 더 쉽습니다.코드 적용 범위를 사용하여 보장하는 경우 저것 모든 것이 테스트되면(그 이상의 테스트 품질을 나타내는 지표가 아님) 진술 적용 범위가 충분할 것입니다.
지점 적용 범위:분기 논리가 있는 경우(예:안 if), 두 가지 모두 평가되었습니까?이는 더 나은 이해를 제공합니다. 논리적 적용 범위 귀하의 코드 중:내 코드가 취할 수 있는 가능한 경로 중 몇 개를 테스트했습니까?
- 이러한 종류의 적용 범위는 프로그램이 포괄적인 입력 세트에 걸쳐 테스트되었음을 나타내는 훨씬 더 나은 지표입니다.정확성에 대한 확신을 위한 최선의 경험적 근사치로 코드 적용 범위를 사용하는 경우 분기 적용 범위 또는 유사한 기준을 기준으로 표준을 설정해야 합니다.

다른 많은 측정항목이 있습니다(줄 범위는 명령문 범위와 유사하지만 예를 들어 여러 줄 명령문에 대해 다른 수치 결과를 생성합니다.조건부 적용 범위 및 경로 적용 범위는 분기 적용 범위와 유사하지만 발생할 수 있는 프로그램 실행의 가능한 순열에 대한 보다 자세한 보기를 반영합니다.)

요구되는 비율

마지막으로 원래 질문으로 돌아갑니다.코드 적용 범위 표준을 설정하면 그 숫자는 어떻게 되어야 합니까?

이 시점에서 우리가 시작하는 근사치에 대해 이야기하고 있다는 것이 분명해졌기를 바랍니다. 따라서 우리가 선택하는 숫자는 본질적으로 근사치가 될 것입니다.

선택할 수 있는 일부 숫자:

100%.모든 것이 테스트되었는지 확인하고 싶기 때문에 이것을 선택할 수 있습니다.이는 테스트 품질에 대한 통찰력을 제공하지는 않지만 일부 품질의 일부 테스트가 모든 문(또는 분기 등)에 영향을 미쳤음을 알려줍니다. 다시 말하지만 이는 신뢰도 수준으로 돌아옵니다.귀하의 보장 범위가 100% 미만인 경우, 알다 코드의 일부 하위 집합은 테스트되지 않았습니다.
- 어떤 사람들은 이것이 어리석은 일이라고 주장할 수도 있으며, 코드에서 정말로 중요한 부분만 테스트해야 합니다.나는 코드에서 정말 중요한 부분만 유지해야 한다고 주장하고 싶습니다.테스트되지 않은 코드를 제거하면 코드 적용 범위도 향상될 수 있습니다.
99% (또는 95%, 기타 90년대 초반의 수치.) 어느 정도의 신뢰도를 전달하려는 경우에 적합합니다. 비슷한 100%로 설정하되 가끔 테스트하기 어려운 코드 부분에 대해 걱정하지 않도록 약간의 여유를 두십시오.
80%.나는 이 번호가 몇 번 사용되는 것을 보았지만 그것이 어디서 유래되었는지 완전히 알지 못합니다.나 생각하다 그것은 80-20 규칙을 이상하게 남용한 것일 수도 있습니다.일반적으로 여기서의 의도는 다음을 보여주는 것입니다. 최대 귀하의 코드가 테스트되었습니다.(예, 51%도 "가장"이지만 80%는 대부분의 사람들이 무엇을 하는지 더 잘 반영합니다. 평균 대부분의 경우.) 이는 "잘 테스트됨"이 높은 우선순위는 아니지만(낮은 가치의 테스트에 노력을 낭비하고 싶지는 않지만) 여전히 우선순위가 충분한 중간 사례에 적합합니다. 어떤 기준을 갖고 싶어합니다.

실제로 80% 미만의 숫자를 본 적이 없으며 이를 설정하는 경우를 상상하기 어렵습니다.이러한 표준의 역할은 정확성에 대한 신뢰도를 높이는 것이며, 80% 미만의 숫자는 특히 신뢰도를 불러일으키지 않습니다.(네, 주관적입니다만, 다시 한번 말씀드리지만 기준을 정할 때 주관적인 선택을 한 번 하시고, 앞으로는 객관적인 측정법을 활용하자는 취지입니다.)

기타 참고 사항

위의 내용은 정확성이 목표라고 가정합니다.코드 적용 범위는 단지 정보일 뿐입니다.다른 목표와 관련이 있을 수 있습니다.예를 들어 유지 관리 가능성에 관심이 있다면 테스트 가능성으로 입증할 수 있고 코드 적용 범위로 (특정 방식으로) 측정할 수 있는 느슨한 결합에 관심이 있을 것입니다.따라서 코드 적용 범위 표준은 "유지 관리 가능성"의 품질을 대략적으로 평가하기 위한 경험적 기반도 제공합니다.

내가 가장 좋아하는 코드 적용 범위는 별표가 있는 100%입니다.별표가 붙은 이유는 특정 줄을 "계산되지 않는" 줄로 표시할 수 있는 도구를 선호하기 때문입니다."계산"되는 줄을 100% 다 덮었다면 완료된 것입니다.

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

나는 생각할 수 있는 모든 기능과 극단적인 경우를 실행하기 위해 테스트를 작성합니다(보통 문서를 사용하여 작업).
코드 적용 도구를 실행합니다.
다루지 않은 줄이나 경로와 중요하지 않거나 도달할 수 없다고 생각하는(방어 프로그래밍으로 인해) 라인이나 경로를 검사하지 않는 것으로 표시합니다.
누락된 줄을 처리하고 이러한 극단적인 사례가 언급되지 않은 경우 문서를 개선하기 위해 새로운 테스트를 작성합니다.

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

테스트 보도에 관해 공유하고 싶은 또 다른 일화가 있습니다.

우리는 트위터를 통해 다음과 같은 거대한 프로젝트를 진행하고 있습니다. 700개의 단위 테스트에서는 코드 적용 범위가 20%에 불과합니다..

스콧 한셀만 라고 대답했다 지혜로운 말들:

오른쪽 20%인가요?사용자가 가장 많이 쳤던 코드를 나타내는 것은 20%입니까?50 개의 테스트를 추가하고 2%만 추가 할 수 있습니다.

또 다시 내 얘기로 돌아간다 코드 적용 범위에 대한 테스트 답변.냄비에 쌀을 얼마나 넣어야합니까?때에 따라 다르지.

이것이 완벽한 세상이라면 코드의 100%가 단위 테스트로 처리될 것입니다.그러나 이것은 완벽한 세상이 아니기 때문에 무엇을 할 시간이 있는지의 문제입니다.따라서 특정 비율에 집중하는 것보다 중요한 영역에 더 집중하는 것이 좋습니다.코드가 잘 작성되었다면(또는 적어도 합당한 복사본이라면) API가 다른 코드에 노출되는 몇 가지 핵심 사항이 있어야 합니다.

이러한 API에 테스트 노력을 집중하세요.API가 1) 잘 문서화되어 있는지, 2) 문서와 일치하는 테스트 사례가 작성되었는지 확인하세요.예상 결과가 문서와 일치하지 않으면 코드, 문서 또는 테스트 사례에 버그가 있는 것입니다.모두 조사해 보는 것이 좋습니다.

행운을 빌어요!

단위 테스트가 처음부터 개발을 주도한 잘 설계된 시스템의 경우 85%는 매우 낮은 숫자라고 말할 수 있습니다.테스트 가능하도록 설계된 소규모 수업은 그보다 더 잘 다루기가 어렵지 않습니다.

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

해당 라인은 테스트된 논리와 동일하지 않으며 백분율을 너무 많이 읽어서는 안 됩니다.

사실입니다. 그러나 코드 적용 범위에 관해 몇 가지 중요한 사항이 있습니다.내 경험상 이 측정항목은 올바르게 사용하면 실제로 매우 유용합니다.그렇긴 하지만, 나는 모든 시스템을 본 것은 아니며 코드 적용 범위 분석이 실제 가치를 추가하는 것을 보기 어려운 시스템이 엄청나게 많다고 확신합니다.코드는 매우 다르게 보일 수 있으며 사용 가능한 테스트 프레임워크의 범위도 다양할 수 있습니다.

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

코드 적용 범위 측정법을 사용할 때 충족해야 하는 고정된(임의의) 비율만 있어서는 안 됩니다. 내 생각에는 이렇게 하면 코드 범위 분석의 실제 이점을 얻을 수 없습니다.대신 다음 측정항목을 정의하세요.

LWM(Low Water Mark)은 테스트 중인 시스템에서 발견된 가장 낮은 수의 노출된 라인입니다.
HWM(High Water Mark)은 테스트 중인 시스템에서 볼 수 있는 가장 높은 코드 적용률입니다.

새 코드는 LWM보다 높지 않고 HWM보다 낮지 않은 경우에만 추가할 수 있습니다.즉, 코드 커버리지는 감소는 허용되지 않음, 새 코드를 다루어야 합니다.내가 어떻게 해야 하고 하지 말아야 한다고 말하는지 주목하세요(아래 설명 참조).

하지만 이것은 더 이상 사용하지 않는 오래되고 잘 테스트된 쓰레기를 치우는 것이 불가능하다는 것을 의미하지 않습니까?그렇습니다. 그렇기 때문에 이러한 일에 대해 실용적이어야 합니다.규칙을 깨야 하는 상황이 있지만, 일반적인 일상적인 통합에는 이러한 측정항목이 매우 유용하다는 것을 경험해봤습니다.이는 다음과 같은 두 가지 의미를 제공합니다.

테스트 가능한 코드가 승격됩니다.새 코드를 추가할 때는 코드를 테스트 가능하게 만들기 위해 정말로 노력해야 합니다. 왜냐하면 테스트 케이스로 모든 코드를 다루려고 노력해야 하기 때문입니다.테스트 가능한 코드는 일반적으로 좋은 것입니다.
레거시 코드에 대한 테스트 범위는 시간이 지남에 따라 증가하고 있습니다.새로운 코드를 추가했는데 테스트 사례로 이를 다룰 수 없는 경우 LWM 규칙을 회피하기 위해 일부 레거시 코드를 다루려고 시도할 수 있습니다.때때로 필요한 부정 행위는 적어도 시간이 지남에 따라 레거시 코드의 적용 범위가 증가한다는 긍정적인 부작용을 제공하여 겉으로는 엄격해 보이는 이러한 규칙의 시행을 실제로는 상당히 실용적으로 만듭니다.

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

또한 코드 적용 범위 측정항목의 일반적인 이점 두 가지를 더 언급하고 싶습니다.

코드 적용 범위 분석은 동적 코드 분석의 일부입니다(정적 코드 분석과 반대).린트).동적 코드 분석 중에 발견된 문제(purify 제품군과 같은 도구를 사용하여 http://www-03.ibm.com/software/products/en/rational-purify-family)은 초기화되지 않은 메모리 읽기(UMR), 메모리 누수 등과 같은 것입니다. 이러한 문제는 코드가 실행된 테스트 케이스에 포함된 경우에만 발견될 수 있습니다..테스트 케이스에서 가장 다루기 어려운 코드는 일반적으로 시스템의 비정상적인 경우이지만 시스템이 정상적으로 실패하기를 원하는 경우(예:충돌 대신 오류 추적) 동적 코드 분석에서도 비정상적인 경우를 다루기 위해 약간의 노력을 기울이고 싶을 수도 있습니다.약간의 불운으로 인해 UMR은 세그폴트 또는 그보다 더 심각한 문제로 이어질 수 있습니다.
사람들은 새로운 코드를 100% 유지하는 데 자부심을 갖고, 다른 구현 문제와 비슷한 열정으로 테스트 문제에 대해 논의합니다.이 함수를 어떻게 더 테스트하기 쉬운 방식으로 작성할 수 있습니까?이런 비정상적인 사건 등을 어떻게 은폐하려고 하시나요?

그리고 완전성을 위해 부정적인 것입니다.

많은 개발자가 참여하는 대규모 프로젝트에서는 모든 사람이 확실히 테스트 천재가 될 수는 없습니다. 어떤 사람들은 코드가 테스트되었다는 증거로 코드 적용 범위 측정항목을 사용하는 경향이 있는데 이는 사실과 매우 다릅니다., 이 질문에 대한 다른 많은 답변에서 언급했듯이.올바르게 사용하면 좋은 이점을 제공할 수 있는 하나의 측정 항목이지만 잘못 사용하면 실제로 잘못된 테스트로 이어질 수 있습니다.위에서 언급한 매우 중요한 부작용을 제외하고, 해당 라인은 테스트 중인 시스템이 일부 입력 데이터에 대해 해당 라인에 도달할 수 있고 정지 또는 충돌 없이 실행될 수 있다는 것만 보여줍니다.

85%는 체크인 기준을 위한 좋은 출발점이 될 것입니다.

아마도 테스트 중인 하위 시스템/구성 요소의 중요성에 따라 배송 기준에 대해 더 높은 다양한 기준을 선택했을 것입니다.

많은 상점은 테스트를 중요하게 생각하지 않으므로 0보다 높으면 적어도 가치에 대한 감사가 있습니다. 따라서 많은 상점이 여전히 0이므로 0이 아닌 것도 나쁘지 않습니다.

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

나는 또한 이런 말을 들었습니다:100%를 열망하면 80%에 도달할 것입니다.하지만 80%를 열망하면 40%에 도달하게 됩니다.

요점:80:20 규칙을 적용하고 앱의 버그 수를 기준으로 하세요.

나는 cobertura를 사용하며, 백분율에 관계없이 cobertura-check 작업의 값을 최신 상태로 유지하는 것이 좋습니다.최소한 totallinerate 및 totalbranchrate를 현재 적용 범위 바로 아래로 계속 높이십시오. 절대 해당 값을 낮추세요.또한 Ant 빌드 실패 특성을 이 태스크에 연결하십시오.적용 범위 부족으로 인해 빌드가 실패하는 경우 누군가가 추가한 코드를 알고 있지만 테스트하지 않은 것입니다.예:

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

내 코드가 단위 테스트가 충분하지 않다고 생각하고 다음에 무엇을 테스트해야 할지 확신이 없을 때, 커버리지를 사용하여 다음에 무엇을 테스트할지 결정하는 데 도움을 줍니다.

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

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

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

상당한 시간 동안 단위 테스트를 수행했다면 95%+에 접근하지 않을 이유가 없습니다.그러나 최소한 테스트를 처음 접하는 경우에도 항상 80%로 작업했습니다.

이 숫자에는 프로젝트에서 작성된 코드(프레임워크, 플러그인 등 제외)만 포함되어야 하며 외부 코드에 대한 호출로 작성된 코드로 완전히 구성된 특정 클래스를 제외할 수도 있습니다.이런 종류의 호출은 조롱/스텁 처리되어야 합니다.

일반적으로 제가 읽은 여러 엔지니어링 우수 사례 문서에 따르면 단위 테스트에서 새 코드의 80%가 최고의 수익을 내는 지점입니다.CC%를 초과하면 들이는 노력에 비해 결함 수가 줄어듭니다.이는 많은 주요 기업에서 사용하는 모범 사례입니다.

불행하게도 이러한 결과의 대부분은 기업 내부에서 나온 것이므로 제가 알려드릴 수 있는 공개 문헌은 없습니다.

코드 적용 범위는 훌륭하지만 코드에서 얻는 이점이 이를 달성하는 데 드는 비용/노력보다 클 경우에만 가능합니다.

우리는 한동안 80%의 표준을 목표로 작업해 왔지만 이제 막 이를 포기하고 대신 테스트에 더 집중하기로 결정했습니다.복잡한 비즈니스 로직 등에 집중하여,

이 결정은 코드 적용 범위를 추적하고 기존 단위 테스트를 유지하는 데 소요되는 시간이 증가했기 때문에 내려졌습니다.우리는 코드 적용 범위에서 얻는 이점이 이를 달성하기 위해 들이는 노력보다 적은 것으로 간주되는 지점에 도달했다고 느꼈습니다.

나는 자동화된 승인 테스트, 기타 통합 테스트 및 단위 테스트를 조합하여 사용하는 BDD를 선호합니다.나에게 있어서 질문은 자동화된 테스트 스위트의 전체 목표 범위가 무엇이어야 하는가입니다.

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

대답은 프로젝트의 역사에 따라 달라집니다.나는 위의 내용이 처음부터 그런 방식으로 관리되는 프로젝트에서만 실용적이라는 것을 알았습니다.나는 대규모 레거시 프로젝트의 적용 범위를 크게 향상시켰고 그렇게 할 가치가 있었지만, 이전으로 돌아가서 모든 적용 범위의 공백을 메우는 것이 실용적이라는 것을 결코 알지 못했습니다. 왜냐하면 테스트되지 않은 오래된 코드는 올바르게 수행할 만큼 충분히 이해되지 않고 빠르게.

확인해 보세요 Crap4j.이는 직선 코드 적용 범위보다 약간 더 정교한 접근 방식입니다.코드 적용 범위 측정과 복잡성 측정을 결합한 다음 현재 테스트되지 않은 복잡한 코드가 무엇인지 보여줍니다.

이 난제에 대한 나의 대답은 테스트할 수 있는 코드의 라인 범위를 100%, 테스트할 수 없는 코드의 라인 범위를 0%로 하는 것입니다.

현재 Python을 사용하는 방법은 .py 모듈을 두 개의 폴더로 나누는 것입니다.app1/ 및 app2/ 그리고 단위 테스트를 실행할 때 해당 두 폴더의 적용 범위를 계산하고 시각적으로 확인합니다(I ~ 해야 하다 언젠가 자동화) app1의 적용 범위는 100%이고 app2의 적용 범위는 0%입니다.

이 숫자가 표준과 다르다는 것을 발견하면 적용 범위가 표준을 따르도록 코드 디자인을 조사하고 변경합니다.

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

또한 가끔 app2/를 검토하여 거기에 있는 코드를 테스트할 수 있는지 확인하고, 가능하다면 app1/로 이동할 수 있습니다.

이제 전체 적용 범위는 프로젝트 규모에 따라 크게 달라질 수 있으므로 크게 걱정하지 않지만 일반적으로 70%에서 90% 이상을 확인했습니다.

Python을 사용하면 범위를 측정하는 동안 내 앱을 자동으로 실행할 수 있는 스모크 테스트를 고안할 수 있고 스모크 테스트와 단위 테스트 수치를 결합하면 100%의 집계 결과를 얻을 수 있기를 바랍니다.

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

내 생각에 대답은 "시간이 얼마나 있느냐에 따라 다르다"이다.나는 100%를 달성하려고 노력하지만 주어진 시간 내에 그것을 얻지 못하더라도 소란을 피우지 않습니다.

단위 테스트를 작성할 때, 프로덕션 코드를 개발할 때 쓰는 모자와는 다른 모자를 씁니다.테스트된 코드가 주장하는 바가 무엇인지, 이를 깨뜨릴 수 있는 상황은 무엇인지 생각합니다.

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

단위 테스트는 내 코드의 예상 동작에 대한 문서 형식이어야 합니다.특정 입력에 대한 예상 출력과 클라이언트가 포착할 수 있는 예외(내 코드 사용자가 알아야 할 사항은 무엇입니까?)
단위 테스트는 내가 아직 생각하지 못했던 가정 조건을 발견하는 데 도움이 될 것입니다.(내 코드를 안정적이고 강력하게 만드는 방법은 무엇입니까?)

이 두 가지 규칙이 100% 적용 범위를 생성하지 못한다면 그렇게 하십시오.하지만 시간이 나면 발견되지 않은 블록과 라인을 분석하고 단위 테스트가 없는 테스트 사례가 아직 있는지 또는 불필요한 코드를 제거하기 위해 코드를 리팩토링해야 하는지 판단합니다.

이는 귀하의 응용 프로그램에 따라 크게 달라집니다.예를 들어, 일부 애플리케이션은 대부분 단위 테스트가 불가능한 GUI 코드로 구성됩니다.

나는 그러한 흑백 규칙이 있을 수 없다고 생각합니다.
중요한 세부 사항에 특히 주의하면서 코드를 검토해야 합니다.
그러나 테스트되지 않았다면 버그가 있는 것입니다!

짧은 답변:60-80%

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

코드의 중요도에 따라 75%-85% 사이가 좋은 경험 법칙입니다.배송 코드는 확실히 집 유틸리티 등에서보다 더 철저하게 테스트되어야 합니다.

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

한동안 개발을 해왔고 이미 많은 코드가 구현되어 있으며 코드 적용 범위에 대해 생각해야 한다는 것을 이제야 깨닫고 있다면 현재 적용 범위(존재하는 경우)를 확인한 다음 해당 기준을 사용하여 다음을 수행해야 합니다. 각 스프린트(또는 스프린트 기간에 따른 평균 상승)를 설정합니다. 이는 최종 사용자 가치를 계속 제공하면서 코드 부채를 떠안는 것을 의미합니다. (적어도 내 경험에 따르면 최종 사용자는 테스트를 늘리더라도 전혀 신경 쓰지 않습니다. 새로운 기능이 표시되지 않는 경우 적용 범위).

귀하의 도메인에 따라 95%를 목표로 하는 것이 무리한 것은 아니지만 평균적으로 85%에서 90%의 평균 사례를 보게 될 것이라고 말씀드리고 싶습니다.

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

시간이 지남에 따라 커버리지 추세가 어떤지 파악하고 추세가 변화하는 이유를 이해하는 것이 가장 중요할 수 있다고 생각합니다.추세 변화를 좋은 것으로 보는지 나쁜 것으로 보는지는 이유를 분석하는 방법에 따라 달라집니다.

며칠 전까지 우리는 >80%를 목표로 삼았지만, 생성된 코드를 많이 사용한 후에는 %age를 고려하지 않고 오히려 리뷰어가 필요한 적용 범위에 대해 전화하도록 합니다.

Testivus 게시에서 답변 컨텍스트는 두 번째 프로그래머가 되어야 한다고 생각합니다.실용적인 관점에서 이렇게 말하면 우리는 노력해야 할 매개변수/목표가 필요합니다.나는 이것이 아키텍처, 기능(사용자 스토리)을 가지고 있는 코드를 분석하고 숫자를 도출함으로써 Agile 프로세스에서 "테스트"될 수 있다고 생각합니다.통신 분야에서의 내 경험에 따르면 60%가 확인하기에 좋은 값이라고 말하고 싶습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow