이제 사람들이이 질문을 중복하거나 여러 번 요청할 수 있다는 것을 알고 있습니다.이 경우 내 질문에 대한 답변으로 관련 질문에 대한 링크를 부탁드립니다.
최근 코드 범위에 대해 일부 사람들과 의견이 맞지 않았습니다. 100 % 적용 범위가 우수한 품질 테스트를 의미하지 않으며 따라서 양질의 코드를 의미하지 않는다는 주장에 따라 우리 팀이 코드 적용 범위를 완전히보고 싶지 않은 사람들이 있습니다.
나는 Code Coverage가 확실하게 테스트되지 않은 것을 알려주고 그 영역에 집중하도록 도와주는 주장을 팔아서 철회 할 수있었습니다.
(위의 내용은 /programming/695811/pitfalls-of-code-coverage 와 같은 다른 SO 질문에서 비슷한 방식으로 논의되었습니다 )
이 사람들의 주장은 팀은 낮은 품질의 테스트를 신속하게 생성하여 상당한 품질을 추가하지 않으면 서 시간을 낭비함으로써 대응할 수 있다는 것입니다.
나는 그들의 관점을 이해하고 있지만 더 많은 적용 범위 기준을 처리하는 더 강력한 도구 / 프레임 워크를 도입하여 코드 적용에 대한보다 강력한 사례를 만드는 방법을 찾고 있습니다(Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .
내가 찾고있는 것은 그러한 코드 적용 도구와 실습 / 프로세스의 조합에 대한 제안으로 내 제안에 대해 편안하게 느끼면서 그러한 주장에 대응할 수 있습니다.
또한 주관적이지만 코드 범위가 주관적이지만 팀이 코드 품질과 테스트 가치를 더 잘 인식 할 수 있도록 도와 주었으므로 이러한 주장에 대응하는 방법에 대한 귀하의 경험 / 지식을 바탕으로 수반되는 의견 / 제안을 환영합니다.
편집 : 일반적인 코드 범위의 약점에 대한 이해에 대한 혼란을 줄이려면 도구를 참조하지 않거나 Statement Coverage 도구가 많이 있음 을 지적하고 싶습니다 . 사실 여기에 잘못된 것에 관한 좋은 기사가 있습니다 : http://www.bullseye.com/statementCoverage.html
나는 여러 가지 적용 기준과 수준에 더 들어가기 위해 단순한 진술 또는 선 적용 범위 이상을 찾고있었습니다.
참조 : http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria
아이디어가 여러 기준에 따라 적용 범위를 알려 주면 테스트 품질에 대한 합리적인 자동화 된 평가가됩니다. 나는 절대로 라인 커버리지가 좋은 평가라고 말하려고하지 않습니다. 사실 그것은 내 질문의 전제입니다.
편집 :
좋아, 어쩌면 나는 그것을 너무 극적으로 투영했지만, 당신은 요점을 얻는다. 문제는 모든 팀에서 일반적으로 프로세스 / 정책을 균질 / 일관된 방식으로 설정하는 것입니다. 그리고 테스트 품질을 어떻게 보장하고, 시간을 측정하지 않고 보장 된 시간을 어떻게 할당 할 것인지에 대한 두려움이 일반적입니다. 따라서 적절한 프로세스와 올바른 도구를 사용하여 백업 할 때 시간이 낭비되는 프로세스에 시간이 걸리지 않음을 알고 코드 품질을 향상시킬 수있는 측정 가능한 기능을 좋아합니다.
편집 : 지금까지 내가 대답에서 얻은 것 :
- 코드 검토는 테스트 품질을 보장하기위한 테스트를 포함해야합니다.
- Test First 전략은 단순히 적용 범위를 늘리기 위해 작성된 후에 작성된 테스트를 피하는 데 도움이됩니다.
- 단순한 Statement / Line 이외의 테스트 기준을 다루는 대체 도구 탐색
- 발견 된 코드 / 버그 수를 분석하면 적용 범위의 중요성을 이해하고 더 나은 사례를 만들 수 있습니다.
- 가장 중요한 것은 올바른 일을하고 그들의 신념을 위해 싸우기위한 팀의 의견을 신뢰하는 것입니다
- 해당 블록 / 테스트 수-토론 가능하지만 일부 가치 보유
지금까지 멋진 답변에 감사드립니다. 정말 감사합니다. 이 실은 몇 시간 동안의 브레인 스토밍보다 강력합니다.