2011-11-14 3 views
0

프레임 워크 4.0에서 개발 된 asp.net 웹 양식 프로젝트로 작업하고 있습니다. 현재 단위 테스트가 없습니다.코드 적용 범위 분석

현재 단위 테스트 및 통합 테스트를 소개 할 사이트에 새로운 기능을 추가하고 있습니다. 코드 범위 개념에 익숙하지 않아서 새로운 기능에 대한 높은 비율을 달성하기를 희망합니다.

모의 생성을 위해 visual studio 및 rhino mock과 함께 제공되는 통합 테스트 환경을 사용하게 될 것입니다. 새로운 기능의 경우 달성해야 할 코드 범위는 어느 수준입니까? 또한 초보자가 코드 범위를 코딩하려면 사이트의 특정 기능에 대해 어떻게 측정 할 수 있습니까?

답변

7

이 지속적으로 코드 커버리지 단위 테스트에서 95 %에 근접 얻을 수 있습니다,하지만 당신은 필요 항상 당신이 실제로 시험하고있는 것에주의를 기울여야하고, 당신이 조롱 거리가되는 것을 줄여야합니다.

결함이있는 모의를 사용한 단위 테스트로 100 % 코드 커버리지를 갖는 것은 테스트 커버리지가 전혀없는 것보다 나쁩니다. 나쁜 모의는 잘못된 보안 감각으로 이어집니다. 사실 당신이 알지 못했을 때 코드가 실제 세상에서 어떻게 돌아갈 지 알 것입니다. 이 거짓 지식에 자신감을 가지고 있기 때문에 아무것도 알 수 없습니다. 적어도 전혀 테스트하지 않았다면, 당신은 당신의 가이드로서 두려움을 가질 것입니다.

가짜는 훌륭한 테스트 도구이지만, 당신의 모의은 실제 세계가 생각하는 것의 에뮬레이션 이상이 될 수 없다는 것을 명심해야합니다. 일반적으로 실제 코드의 주요 흐름에는 문제가 없습니다. 실제 세계는 이성적인 기대에서 벗어나고, 어떤 곳에서는 당신을 잘못된 보안 감각으로 인도합니다.

일반적으로 실제 시스템에 대해 실행 중이기 때문에 통합 테스팅은 현실감을 향상시킵니다.그러나 통합 테스트에서 오류 사례를 시뮬레이트하여 코드 경로의 모든 모서리 사례를 제거하고 코드 범위의 마지막 5 %를 압축하는 것은 매우 어렵습니다. 단위 테스트는 오류 조건을 강요하고 코드의 오류 처리를 수행하는 데 탁월합니다.

코드 커버리지 통계를 너무 많이 읽지 않도록주의하십시오. 거짓말, 거짓된 거짓말, 코드 커버리지 통계. ;> 코드 커버리지 데이터는 단위 테스트가하는 일에 대한 통찰력을 얻기위한 유용한 도구이지만 절대적인 진실은 아닙니다. 코드 커버리지 결과는 표면적으로 화려하지만 이해를 바탕으로 단련되어야합니다.

전체 코드 적용 도구는 전체적인 이야기를하는 데 어려움을 겪습니다. 가장 간단한 것은 테스트 실행 중에 한 줄의 코드가 실행되었다는 것입니다. 코드 줄을 통해 가능한 모든 코드 경로에서 해당 줄이 실행되는지 알려주지 않습니다. 이유는 코드 경로 순열 수가 추가 if 문 하나마다 기하 급수적으로 증가하기 때문입니다. 그 정도의 성장은 관리하기 어렵고 시각화하기가 어렵습니다.

이 코드를 고려

public class Class1 
{ 
    public static void foo(bool a, bool b) 
    { 
     int x = 100; 
     if (a) 
      Console.WriteLine("statement a"); 
     else 
      x -= 50; 

     if (b) 
      Console.WriteLine("statement c"); 
     else 
      x -= 50; 

     double y = 10/x; 
    } 
} 

[TestClass] 
public class UnitTest1 
{ 
    [TestMethod] 
    public void TestMethod1() 
    { 
     Class1.foo(true, true); 
     Class1.foo(true, false); 
     Class1.foo(false, true); 
    } 
} 

코드 적용 범위이 코드의 모든 라인이 당신의 단위 테스트에 의해 행사되고 있음을 알려드립니다.

축하합니다! 100 % 코드 적용 배지를 획득했습니다. 아, 그런데 코드에 여전히 크래시 버그가 있습니다.

단위 테스트에서 스 니펫의 모든 코드 줄을 연습했기 때문에 적용 결과가 정확합니다. 그러나 그것은 완전한 이야기, 완전한 진리는 아닙니다. 동일한 실행 컨텍스트에서 두 else 절을 ​​통과하는 (a, b) = (false, false)의 코드 경로는 단위 테스트에서 실행되지 않았습니다. 그리고 그것은 현실 세계에서 런타임에 제로 오류로 나누는 원인이 될 수있는 하나의 경로입니다.

잘못 이해하지 마십시오. 단위 테스트는 상어 탱크에서 플레이하기 전에 작업을 점검하는 것이 중요합니다. 코드 커버리지 분석은 코드의 어느 부분이 결코 이 아니 었는지 빠르게 결정할 수있는 매우 강력한 도구입니다.은 하루의 빛을 보았고 출시 전에주의를 기울일만한 가치가 있습니다.

이러한 도구를 사용하여 결과를 신중하게 고려하면 잘 처리 할 수 ​​있습니다.

0

귀하의 질문이 약간 이상합니다.

코드 커버리지는 특정 실행시 실행되는 코드의 양을 나타내는 기준입니다. 일반적으로 사람들은 단위 테스트의 품질을 평가하는 기준으로 코드 커버리지를 사용합니다.이 경우 커버되지 않은 코드는 테스트되지 않은 코드와 같습니다. 그래서 모두가 100 % 여기를보고 싶어합니다. 당신은 프리미엄이나 얼티밋이있는 경우 귀하의 경우에는

당신은 VS2010에서 직접 같은 목적으로 코드 커버리지를 사용할 수 있습니다 : 당신이 UI처럼, 테스트의 다른 유형을 사용할 수 있습니다 ASP.NET 응용 프로그램의 http://msdn.microsoft.com/en-us/library/ms243186.aspx

VS2010에서 (부분적으로) 생성하고 실행할 수있는 테스트 (웹 폼 용),로드 테스트 등.

2

내 의견으로는 코드 검사는 단위 테스트를 할 때 오도 된 측정 항목입니다. 높은 보상은 당신에게 좋은 단위 테스트가 있다고 말하지 않습니다. 실제로 아무것도 테스트하지 않는 동안 100 % 커버리지를 갖는 것은 매우 쉽습니다. 또한 unittesting에 대한 흥미로운 범위는 분기 커버리지이지만 대부분의 툴은 라인 커버리지를 제공합니다.

대신해야 할 일은 TDD의 올바른 수행 방법을 스스로에게 알리는 것입니다. 적절한 TDD를 사용하면 좋은 단위 테스트를받을 수 있으며 측정을하지 않고도 매우 우수한 적용 범위를 확보 할 수 있습니다.

0

이 테스트를 통해 자신의 기능에 자신감을 가지게되고 코드 커버리지가 테스트에 대한 확신을 갖게되고 물론 코드 커버리지만큼이나 자신감이 향상됩니다.

그러나 사업을 충족하지 않는 기능에 대한이 자신감을 기억하지만, 예상치 못한 예외 날려되지 않습니다 코드에 대해

+0

단위 테스트는 예외 사항을 확인하는 것이 좋을까요? 나는 그것이 단위 테스트가 무엇인지 놓치고 있다고 생각합니다. – svick

+0

미안 해요 올바른 어구를 놓쳐서 죄송합니다. 어쩌면 영어가 모국어가 아니기 때문에 어쨌든 모든 컴파일 시간 오류를 커버하는 응용 프로그램을 빌드 할 때 단위 테스트가 모든 런타임 오류를 상당 부분 포함한다고 말하고 싶습니다. 기존 코드 커버리지 비율로 코드 적용 범위의 높은 비율이 애플리케이션을 의미하지 않는다는 점을 강조하고 싶습니다. –

관련 문제