코드 덮어쓰기는 무용하다

얼마 전까지만 해도 사무실 안에서 새로운 테스트 계획에 대해 토론을 진행했다.지금 그 자체로 말하자면, 이것은 매우 좋은 소식이다.누가 우리의 테스트 이야기가 표준에 도달하는 데 시간을 좀 들이고 싶지 않겠습니까?
문제는 우리가 적어도 80%의 테스트 커버율을 확보해야 한다는 것이다.
비록 목적은 좋지만 유감스럽게도 코드 커버율은 쓸모가 없다.

지금, 이것은 매우 대담한 성명이므로, 내가 좀 분명하게 밝히도록 한다.코드 덮어쓰기 목표는 무용합니다.주어진 코드 기반에서 X% 의 덮어쓰기를 쟁취해서는 안 됩니다.이것은 몇 가지 이유가 있으니 내가 설명해 줄게.

충분한 테스트를 할 수 있다

모든 코드 기반이 평등하게 만들어진 것은 아니다.하나는 하루에 수백만 뷰의 조회수를 볼 수 있는 응용 프로그램일 수도 있고 매우 복잡하다.또 하나는 매일 몇 명의 사용자에게 서비스를 제공하는 작은 응용 프로그램일 수도 있다.나는 항상 위험 차원에서 이런 서로 다른 유형의 응용 프로그램을 구상하는 것을 좋아한다.

네가 원한다면, 모든 점이 우리 시스템의 응용 프로그램이라고 상상해 봐라.우리가 오른쪽 위로 올라갈수록 문제가 발생할 가능성이 높아진다. 이것은 약간의 나쁜 소식이 쇠퇴할 것이다.왼쪽 아래.응?아마도 누군가가 알아차릴 것이다.
현재, 모든 응용 프로그램이 적어도 80%의 코드 커버율을 가지고 있어야 한다면, 그것은 좀 어리석다.왜?기회 원가.비록 나는 테스트의 확고한 지지자이지만, 테스트를 좋아하지 않는 것은 단지 때문이다.우리의 목표는 반드시 충분한 테스트를 진행하는 것이다.응용 프로그램이 예상대로 실행될 수 있도록 충분한 테스트를 실시합니다.
실제로 우리 우익의 응용 프로그램에 있어서 80퍼센트는 부족하다.아마도 이것은 사실상 더 높아야 할 것이다. 우리는 80퍼센트에 머물러서는 안 된다.다른 한편, 왼쪽 아래 모서리의 작은 응용 프로그램은 이렇게 높은 커버율을 필요로 하지 않을 수도 있다.테스트를 추가하는 데 걸리는 주기는 우리에게 매우 적고 심지어 가치도 없으며, 결국은 시간만 낭비할 뿐이다.
주의: 이 점에서 일부 사람들은 테스트 추가의 가치에 대해 곤혹스러워할 수 있다고 생각합니다.TDD라는 완전한 개발 방법이 있는데 빨간색, 녹색, 재구성 주기에 따라 높은 수준의 커버율을 만들 수 있다.내가 여기서 제시한 요점은 일반적으로 반환하고 테스트를 추가하는 것을 가리킨다. 왜냐하면 코드 기반 커버율이 너무 낮다는 지적이 있기 때문이다.만약 당신이 TDD를 하기 시작한다면, 목표를 설정하는 것은 정말 도움이 되지 않을 것이다.이것은 단지 부산물일 뿐이다.
이것은 모두 언어 환경에 관한 것이다.우리는 코드 라이브러리마다 커버율의 백분율을 요약할 수 없다. 왜냐하면 모든 코드 라이브러리는 다르기 때문이다.
흥미로운 사실: 당신은 이런 위험 평면도가 많은 다른 장면에 적용될 수 있다는 것을 알고 있습니까?경비원의 위험 비행기가 어떤 모습인지 생각해 본 적이 있습니까?

어쨌든
마찬가지로 매사에 테스트가 필요한 것은 아니다.만약 우리가 우리의 코드 라이브러리에 새로운 공공 구성원을 도입하고 싶다면, 이것은 매우 간단하다

public FirstName { get; set; } 

만약 우리의 어떤 테스트에서도 이 코드를 호출하지 않았다면, 이 코드를 도입하면 코드 커버율을 낮출 수 있습니다.심지어 우리가 사랑하는 80%보다 낮을 수도 있다.복구?

[Fact]
public void FirstName_ByDefault_CanBeSet()  
{
  var myClass = MyClass();
  myClass.FirstName = "testname";
  Assert.AreEqual("testname", myClass.FirstName)
}

이 점에서 우리는 단지 테스트일 뿐이다.NET--이것은 우리가 절대로 피하고 싶은 것이다.나는 실제로 내가 원하지 않는 방식으로 바뀔 수 있다는 것만 테스트하는 경향이 있다.논리 코드.

코드 덮어쓰기가 쉬워요.

단지 우리가 많은 코드 커버율을 가지고 있기 때문에, 반드시 우리가 우리의 응용 프로그램에 대해 예상한 대로 일을 할 수 있다는 것을 의미하지는 않는다.예를 들면 모든 것이 더욱 뚜렷해지기 때문에 다음과 같은 몇 가지를 고려해 봅시다.

public class Flawless  
{
  public bool IsGuarenteedToWork()
  {
    // some code
  }
}

현재, 방법은 통상적으로 우리가 테스트하고 싶은 논리가 있다. 그렇지?조건문, 수학 연산, 마음대로 말해.그러나 우리의 예로 말하자면, 이것은 결코 중요하지 않다.우리는 단지 코드 커버율을 늘리고 싶을 뿐이다.이것은 우리의 목표다.

[Fact]
public void IsGuarenteedToWork_ByDefault_Works()  
{
  var flawless = new Flawless();

  var actual = flawless.IsGuarenteedToWork();
}

여기 있다!100% 코드 덮어쓰기.기본적으로 없음Assert의 테스트는 통과된 것으로 간주됩니다.지금 생각하고 있을지도 몰라.오, 제발, 누가 정말 이렇게 할 거야?
격려를 받을 때 사람들은 바보짓을 한다.내가 예를 들면 한 장면이다. 이 장면에서 한 회사가 QA에 그들이 분기 말에 발견한 모든 버그에 대해 그들은 상금을 받을 것이라고 말했다.보기에 매우 합리적이지, 그렇지?다른 한편, 같은 회사는 개발 부서에 시스템을 도입한 버그 수량에 따라 보너스를 받을 것이라고 말했다.
이런 상황은 대립 단체의 실패를 자극했다.개발 조직은 버그를 도입하는 것이 두렵고 QA가 분석에서 버그를 무시하기를 바라기 때문에 정말 어떤 코드도 쓰고 싶지 않다.QA팀은 개발자가 오류를 찾을 수 있도록 시스템에 오류를 도입하여 보상을 받기를 바란다.
우리가 기억해야 할 또 다른 일은...

코드 덮어쓰기 상하문 문제

우리 개발자들은 시스템 게임을 시도하는 것이 아니라 코드 커버율 목표를 실현하기 위해 진지한 노력을 기울였다는 것을 고려해 봅시다.우리의 실현은 다음과 같다.

public class Flawless  
{
  public bool IsGuarenteedToWork()
  {
    for(var x = 0; x < int.MaxValue; x++) 
    {
      // Man, this is gonna work. I'll find that solution.. eventually.
    }
  }
}

.. 시험을 잊지 마라.

[Fact]
public void IsGuarenteedToWork_ByDefault_Works()  
{
  var flawless = new Flawless();

  var actual = flawless.IsGuarenteedToWork();

  Assert.True(actual);
}

나는 위의 예가 전혀 나타나지 않았다는 것이 분명하기를 바란다.그러나 이런 상황에서 우리는 이미 100%의 코드 커버율에 이르렀다. 우리는 사실상 코드가 우리의 기대에 따라 작업한다고 단언하고 있다.실시가 유효하다.테스트가 정확합니다.모두들 매우 즐겁다.거의.
테스트하면 서로 다른 이해관계자가 있다.

Stakeholders are people whose lives you touch - Mark McNeil

이것은 이해관계자의 유형으로 한층 더 세분화할 수 있다.

주요 이해관계자(나의 경우): 이 기능을 요청하는 고객.

부차적인 이해관계자(직접 참여한 다른 사람) 예: 당신의 사장과/또는 프로젝트의 다른 개발자.

간접 이해관계자(다른 영향을 받은 사람) 예: 고객의 고객.

프로그래머로서 우리가 코드를 작성하는 것은 다른 사람의 문제를 해결하기 위해서이다.같은 코드는 서로 다른 사람에게 서로 다른 영향을 미친다.A는 답이 맞는지에만 관심을 갖는다.아마도 그들은 준비가 다 된 후에 통지를 받을 것이다. 그러나 그들은 통지를 받는 시간에 대해 무관심하다.B는 요청을 한 지 얼마 되지 않아 답이 필요하다.우리의 테스트는 A만 완전히 만족시켰다.
코드를 작성할 때 이해관계자가 많을 수 있다.불행하게도, 100%의 코드 커버율에서도 우리는 우리의 코드가 모든 사람의 수요와 호환될 것이라고 자신할 수 없다.
왜 코드 덮어쓰기가 목표로 쓸모없는지 반복해서 토론한 후에마지막으로 말하겠다...

코드 커버율은 실제로 유용하다

나는 코드 커버율을 평가 기준으로 삼는 것을 더욱 좋아한다.커버율은 우리가 알고 있는 것이다. 우리는 모든 코드 라이브러리에 대해 현명한 결정을 내릴 수 있다.
만약 우리가 코드 기반의 커버율이 계속 떨어지고 있다는 것을 발견한다면, 우리는 그것을 신호로 삼아 현재 발생하고 있는 일을 더욱 깊이 있게 이해할 수 있다.코드 라이브러리는 믿을 수 없을 정도로 테스트하기 어렵습니까?개발자는 설령 의미가 있다 하더라도 테스트를 열심히 하지 않았을 뿐입니까?아마도 이것은 사실상 우리가 코드 라이브러리에서 기대하는 것이기 때문에 모든 것이 매우 중요하다.
만약 우리가 충분한 테스트를 했다면, 커버율도 우리에게 알려줄 수 있다.만약 임무 관건적인 응용 프로그램이 10퍼센트의 커버율만 있다면, 우리는 그 원인을 조사하고 품질 계획을 시작하여 테스트를 진행해야 한다.그것은 무작위로 코드 라이브러리를 선택하고 테스트를 시작하는 것이 아니라 테스트 계획을 우선적으로 고려할 수 있도록 한다.
이 모든 것들의 모든 요점은 덮어쓰기 목표를 설정하면 그 반대일 뿐이다.우리는 커버율을 의식해야 한다. 이렇게 하면 현명한 결정을 내릴 수 있지만, 커버율을 달성하기 위해서만 코드의 질에 영향을 주어서는 안 된다.