테스트 목적으로 코드를 엄격하게 수정하는 것은 나쁜 습관입니까?

프로그래머 동료와 토론하여 작업 코드를 수정하여 테스트 할 수 있도록 (예 : 단위 테스트를 통해) 좋은지 나쁜지에 대한 토론이 있습니다.

제 생각에는 좋은 객체 지향 및 소프트웨어 엔지니어링 관행 ( "모든 것을 공개하는 것"등)을 유지하는 한도 내에서 괜찮다는 것입니다.

내 동료의 의견은 테스트 목적으로 만 코드를 수정하는 것이 잘못되었다는 것입니다.

간단한 예를 들면, C #으로 작성된 일부 구성 요소에서 사용하는이 코드 조각을 생각해보십시오.

public void DoSomethingOnAllTypes()
{
    var types = Assembly.GetExecutingAssembly().GetTypes();

    foreach (var currentType in types)
    {
        // do something with this type (e.g: read it's attributes, process, etc).
    }
}

이 코드는 실제 작업을 수행하는 다른 메소드를 호출하도록 수정할 수 있다고 제안했습니다.

public void DoSomething(Assembly asm)
{
    // not relying on Assembly.GetExecutingAssembly() anymore...
}

이 방법은 Assembly 객체를 처리하여 자체 어셈블리를 전달하여 테스트를 수행 할 수 있도록합니다. 제 동료는 이것이 좋은 습관이라고 생각하지 않았습니다.

좋은 관행은 무엇입니까?

보다 테스트 가능하도록 코드를 수정하면 테스트 가능성 이상의 이점이 있습니다. 일반적으로 더 테스트 가능한 코드

• 유지 관리가 더 쉽고
• 추론하기 쉬우 며
• 더 느슨하게 결합되어 있으며
• 전체적으로 더 나은 디자인을 가지고 있습니다.

(겉보기)가 있습니다 반대 세력 플레이는.

• 한편으로는 캡슐화를 시행하려고합니다.
• 반면에, 당신은 소프트웨어를 테스트 할 수 있기를 원합니다

모든 '구현 세부 사항'을 비공개로 유지하려는 제안자는 일반적으로 캡슐화를 유지하려는 욕구에 의해 동기가 부여됩니다. 그러나 모든 것을 잠그고 사용할 수없는 상태로 유지하는 것은 캡슐화에 대한 오해 입니다. 모든 것을 사용할 수없는 상태로 유지하는 것이 궁극적 인 목표라면 캡슐화 된 유일한 코드는 다음과 같습니다.

static void Main(string[] args)

동료가 이것을 코드의 유일한 액세스 포인트로 만들 것을 제안하고 있습니까? 외부 발신자가 다른 모든 코드에 액세스 할 수 없습니까?

거의. 그렇다면 어떤 방법을 공개해도 좋을까요? 결국 주관적인 디자인 결정이 아닙니까?

좀 빠지는. 무의식 수준에서도 프로그래머를 안내하는 경향은 캡슐화의 개념입니다. 변하지 않는 것을 적절히 보호 할 때 공개적인 방법을 노출시키는 것이 안전하다고 생각합니다 .

나는 그것의 불변을 보호하지 않는 개인 방법을 보여주고 싶지 않을 것이다, 그러나 수시로 당신이 있도록 수정할 수 있습니다 않습니다 자사의 불변을 보호하고, 다음 TDD와 함께 (물론, 대중에 노출, 당신은 그것을 할 다른 방법으로).

실제로하고있는 것은 Open / Closed Principle을 적용 하기 때문에 테스트 가능성을 위해 API를 여는 것이 좋습니다 .

API 호출자가 한 명 뿐인 경우 API가 실제로 얼마나 유연한 지 알 수 없습니다. 아마 융통성이 없습니다. 테스트는 두 번째 클라이언트 역할 을하여 API의 유연성에 대한 귀중한 피드백을 제공합니다 .

따라서 테스트에서 API를 열어야한다고 제안하면 수행하십시오. 복잡성을 숨기지 않고, 안전한 방법으로 복잡성을 노출시켜 캡슐화를 유지합니다.

의존성 주입 에 대해 이야기하고있는 것 같습니다 . 실제로는 일반적이며 IMO는 테스트 가능성에 매우 필요합니다.

코드를 테스트 가능하게 만들기 위해 코드를 수정하는 것이 좋은 아이디어인지에 대한 광범위한 질문을 해결하려면 다음과 같이 생각하십시오. 코드에는 a) 실행, b) 인간이 읽을 수있는 c, 테스트. 세 가지 모두 중요하며 코드가 세 가지 책임을 모두 수행하지 못하면 코드가 좋지 않다고 말하고 싶습니다. 따라서 수정하십시오!

약간의 닭고기와 계란 문제입니다.

코드의 테스트 범위가 좋은 가장 큰 이유 중 하나는 두려움없이 리팩토링 할 수 있기 때문입니다. 그러나 테스트 범위를 넓히려면 코드를 리팩터링해야하는 상황에 처해 있습니다! 그리고 당신의 동료는 두렵습니다.

동료의 관점을 봅니다. 당신은 (아마도) 작동하는 코드를 가지고 있으며, 어떤 이유로 든 리팩토링하면 그것을 깨뜨릴 위험이 있습니다.

그러나이 코드가 지속적인 유지 관리 및 수정이 필요한 코드 인 경우 작업을 수행 할 때마다 위험을 감수해야합니다. 그리고 리팩토링 지금 어떤 테스트 커버리지를 받고 지금 당신이 통제 된 조건 하에서, 그 위험을 감수하고, 미래의 수정을위한 더 나은 모양으로 코드를 얻을 수 있습니다.

따라서이 특정 코드베이스가 상당히 정적이고 미래에 중요한 작업을 수행 할 것으로 예상되지 않는 한, 원하는 것은 훌륭한 기술 관행입니다.

물론, 그것이 좋은 사업 관행 인지 여부 는 웜의 또 다른 캔입니다.

이것은 단지 다른 답변에서 강조에 차이가있을 수 있습니다,하지만 난 코드가해야한다고 말하고 싶지만 하지 리팩토링 할 수 엄격하게 테스트 용이성을 개선 할 수 있습니다. 테스트 가능성은 유지 관리에 매우 중요하지만 테스트 자체는 끝 이 아닙니다 . 따라서이 코드가 비즈니스 목적을 더욱 발전시키기 위해 유지 보수가 필요할 것으로 예상 할 때까지 이러한 리팩토링을 연기합니다.

이 코드는 약간의 유지 보수를 필요로 할 것을 결정하는 시점에서, 그 테스트 용이성을 위해 리팩토링 할 수있는 좋은 시간이 될 것입니다. 귀하의 비즈니스 사례에 따라 모든 코드에 결국 약간의 유지 보수가 필요 하다고 가정 할 수 있습니다. 이 경우 다른 답변 ( 예 : Jason Swett의 답변 )으로 그린 구별이 사라집니다.

요약하면 : 테스트 가능성만으로는 코드 기반을 리팩토링 할 수있는 충분한 이유가 아닙니다. 테스트 가능성은 코드 기반을 유지 관리하는 데 중요한 역할을하지만 리팩토링을 유도하는 코드 기능을 수정하는 것은 비즈니스 요구 사항입니다. 그러한 비즈니스 요구 사항이 없다면 고객이 관심을 가질만한 일을하는 것이 좋습니다.

(물론 새로운 코드는 활발히 유지되고 있으므로 테스트 할 수 있도록 작성해야합니다.)

동료가 틀렸다고 생각합니다.

다른 사람들은 이것이 이미 좋은 이유를 언급했지만, 당신이 이것을하기 위해 앞서가는 한, 당신은 괜찮을 것입니다.

이 경고의 이유는 코드를 변경하면 코드를 다시 테스트해야하기 때문에 발생합니다. 수행 한 작업에 따라이 테스트 작업 자체가 실제로 큰 노력 일 수 있습니다.

리팩토링 결정과 회사 / 고객에게 도움이 될 새로운 기능에 대한 결정을 내릴 필요는 없습니다.

코드를 통한 모든 경로가 실행되는지 확인하기 위해 단위 테스트의 일부로 코드 적용 도구를 사용했습니다. 나 자신에 대한 꽤 좋은 코더 / 테스터로서, 나는 보통 코드 경로의 80-90 %를 다루고 있습니다.

발견되지 않은 길을 연구하고 그 중 일부를 위해 노력할 때, "절대 일어나지 않을"오류 사례와 같은 버그를 발견하게됩니다. 따라서 코드를 수정하고 테스트 범위를 확인하면 코드가 향상됩니다.

여기서 문제는 테스트 도구가 쓰레기라는 것입니다. 이 간단한 예제는 정말 간단하고 수정하기 쉽지만 훨씬 더 복잡한 일이 발생하기 때문에 해당 객체를 모의하고 테스트 메소드를 변경하지 않고 호출 할 수 있어야합니다.

많은 사람들이 이러한 코드 변경이 필요한 조롱 및 단위 테스트 도구를 사용하여 단위 테스트를 가능하게하기 위해 IoC, DI 및 인터페이스 기반 클래스를 도입하기 위해 코드를 수정했습니다. 나는 그것들이 건강하다는 것을 얇게 생각하지 않습니다. 매우 간단하고 간단한 코드가 각각의 모든 클래스 메소드를 다른 모든 것과 완전히 분리시켜야 할 필요성으로 인해 복잡한 상호 작용의 악몽 혼란으로 바뀌는 것을 볼 때 . 그리고 부상에 대한 모욕을 추가하기 위해 개인 메소드를 단위 테스트해야하는지 여부에 대한 많은 논란이 있습니다! (물론 그들은 무엇을해야합니까?

물론 문제는 테스트 툴링의 특성에 있습니다.

이러한 설계 변경 사항을 영원히 적용 할 수있는 더 나은 도구가 제공됩니다. Microsoft에는 정적 객체를 포함하여 콘크리트 객체를 스터브 할 수있는 가짜 (nee Moles)가 있으므로 더 이상 도구에 맞게 코드를 변경할 필요가 없습니다. 귀하의 경우 Fakes를 사용하는 경우 GetTypes 호출을 유효하고 유효하지 않은 테스트 데이터를 반환 한 자신의 것으로 바꾸어야합니다. 이는 매우 중요하지만 제안 된 변경은 전혀 제공하지 않습니다.

대답 : 동료는 옳지 만 잘못된 이유로 가능합니다. 테스트 할 코드를 변경하거나 테스트 도구 (또는 전체 테스트 전략을 세분화하지 않고보다 통합적인 단위 테스트를 수행하도록 변경)를 변경하지 마십시오.

Martin Fowler는 그의 기사 Mocks aren 's Stubs 에서이 영역에 대해 토론했습니다.

일반적으로 단위 테스트 및 디버그 로그 를 사용하는 것이 좋습니다 . 단위 테스트를 통해 프로그램을 더 변경해도 이전 기능이 중단되지 않는지 확인할 수 있습니다. 디버그 로그는 런타임시 프로그램을 추적하는 데 도움이됩니다.
때로는 그 이상으로도 테스트 목적으로 만 무언가가 필요합니다. 이를 위해 코드를 변경하는 것은 드문 일이 아닙니다. 그러나 이로 인해 프로덕션 코드가 영향을받지 않도록주의해야합니다. C ++ 및 C에서는 컴파일 시간 엔터티 인 MACRO를 사용하여이 작업을 수행합니다 . 그런 다음 프로덕션 환경에서는 테스트 코드가 전혀 표시되지 않습니다. 그러한 조항이 C #에 있는지 모릅니다.
또한 프로그램에 테스트 코드를 추가 할 때 명확하게 표시 되어야합니다이 코드 부분은 테스트 목적으로 추가되었습니다. 그렇지 않으면 코드를 이해하려는 개발자는 단순히 코드의 해당 부분에 땀을 흘릴 것입니다.

예제 간에는 몇 가지 심각한 차이점이 있습니다. 의 경우 현재 어셈블리의 유형에 적용 할 수 DoSomethingOnAllTypes()있는 의미가 do something있습니다. 그러나 DoSomething(Assembly asm)명시 적으로 당신이 통과 할 수 있음을 나타냅니다 어떤 그것에 어셈블리.

내가 지적한 이유는 테스트를위한 많은 의존성 주입 전용 단계가 원래 객체의 경계를 벗어난 단계이기 때문입니다. 나는 당신이 " '모든 것을 공개하는 것 "이 아니라고 말 했지만, 그것은 그 모델의 가장 큰 오류 중 하나이며, 그다음에 밀접하게 사용됩니다.

귀하의 질문에 동료가 주장한 내용이 많지 않아 추측의 여지가 있습니다.

"나쁜 연습"여부가에 따라 방법 과 때 변경이 이루어집니다.

내 선택에 따라 방법을 추출하는 예제 DoSomething(types)는 괜찮습니다.

그러나 나는 이것처럼 좋지 않은 코드를 보았다 :

public void DoSomethingOnAllTypes()
{
  var types = (!testmode) 
      ? Assembly.GetExecutingAssembly().GetTypes() 
      : getTypesFromTestgenerator();

  foreach (var currentType in types)
  {
     if (!testmode)
     {
        // do something with this type that made the unittest fail and should be skipped.
     }
     // do something with this type (e.g: read it's attributes, process, etc).
  }
}

이러한 변경 사항으로 인해 가능한 코드 경로 수가 증가했기 때문에 코드를 이해하기가 더 어려워졌습니다.

내가 뭘으로 의미 하는 방법 과 때 :

실제 구현이 있고 "테스트 기능 구현"을 위해 변경 한 경우 DoSomething()메소드 가 손상되었을 수 있으므로 애플리케이션을 다시 테스트해야합니다 .

는 if (!testmode)추출 방법보다 더 이해하기 difficulilt 및 테스트입니다.