테스트 주도 개발 (및 애자일)의 이러한 제한이 실질적으로 관련이 있습니까?

TDD (Test Driven Development)에서는 차선책으로 시작한 다음 테스트 사례를 추가하고 리팩토링하여 더 나은 솔루션을 반복적으로 생성합니다. 단계는 작아야하는데, 이는 각각의 새로운 솔루션이 어떻게 든 이전 솔루션 근처에 있다는 것을 의미합니다.

이는 그라데이션 하강 또는 로컬 검색과 같은 수학적 로컬 최적화 방법과 유사합니다. 이러한 방법의 잘 알려진 한계는 그것이 글로벌 최적 또는 심지어 허용 가능한 지역 최적을 찾도록 보장하지 않는다는 것입니다. 시작 지점이 불량 솔루션의 넓은 영역에 의해 수용 가능한 모든 솔루션과 분리되어 있으면 도달 할 수 없으며 방법이 실패합니다.

더 구체적으로 말하면 : 나는 당신이 많은 테스트 사례를 구현 한 시나리오를 생각하고 있으며 다음 테스트 사례는 경쟁적으로 다른 접근법을 요구할 것입니다. 이전 작업을 버리고 다시 시작해야합니다.

이 생각은 실제로 TDD뿐만 아니라 작은 단계로 진행되는 모든 민첩한 방법에도 적용될 수 있습니다. 이 제안 된 TDD와 로컬 최적화 간의 유추에 심각한 결함이 있습니까?

이러한 방법의 잘 알려진 한계는 그것이 글로벌 최적 또는 심지어 허용 가능한 로컬 최적을 찾도록 보장하지 않는다는 것입니다.

비교를보다 적절하게하기 위해, 어떤 종류의 문제의 경우, 반복 최적화 알고리즘은 좋은 로컬 최적화를 생성 할 가능성이 매우 높으며, 다른 상황에서는 실패 할 수 있습니다.

여러 테스트 사례를 구현 한 시나리오를 생각하고 있으며 다음 테스트 사례에는 경쟁 방식이 다른 접근법이 필요하다는 것을 알게되었습니다. 이전 작업을 버리고 다시 시작해야합니다.

실제로 발생할 수있는 상황을 상상할 수 있습니다 . 잘못된 아키텍처 를 선택할 때 기존의 모든 테스트를 처음부터 다시 작성해야합니다. 운영 체제 A에서 프로그래밍 언어 X로 첫 20 개의 테스트 사례를 구현한다고 가정 해 봅시다. 불행히도 요구 사항 21에는 전체 프로그램을 운영 체제 B에서 실행해야하며 X는 사용할 수 없습니다. 따라서 언어 Y로 대부분의 작업과 재 구현을 버려야합니다. 물론 코드를 완전히 버리지 않고 새로운 언어와 시스템으로 이식해야합니다.

이것은 TDD를 사용하는 경우에도 미리 전체적인 분석 및 설계를 수행하는 것이 좋습니다. 그러나 이것은 다른 종류의 접근 방식에도 해당되므로 고유 한 TDD 문제로 보지 않습니다. 또한 대부분의 실제 프로그래밍 작업에서 표준 아키텍처 (예 : 프로그래밍 언어 X, 운영 체제 Y, 하드웨어 XYZ의 데이터베이스 시스템 Z)를 선택할 수 있으며 TDD와 같은 반복적이거나 민첩한 방법론을 비교적 확신 할 수 있습니다 막 다른 골목으로 당신을 데려 가지 않습니다.

Robert Harvey 인용 : "단위 테스트에서 아키텍처를 확장 할 수 없습니다." 또는 pdr : "TDD는 최고의 디자인을 완성하는 데 도움이 될뿐 아니라 더 적은 노력으로 더 많은 도움을 얻을 수 있습니다."

실제로 당신이 쓴 것은

시작 지점이 불량 솔루션의 넓은 영역에 의해 수용 가능한 모든 솔루션과 분리되어 있으면 도달 할 수 없으며 방법이 실패합니다.

잘못된 아키텍처를 선택하면 필요한 솔루션에 도달하지 못할 수 있습니다.

반면에, 사전에 전체 계획을 세우고 올바른 아키텍처를 선택할 때 TDD를 사용하는 것은 "전역 최대 값"(또는 적어도 충분한 최대 값)에 도달 할 수있는 영역에서 반복 검색 알고리즘을 시작하는 것과 같아야합니다. ) 몇 번의 주기로.

TDD에 로컬 최대 값에 문제가 있다고 생각하지 않습니다. 올바르게 알고 있듯이 작성하는 코드는 리팩토링 (기능 변경없이 코드 재 작성)이 사용되는 이유입니다. 기본적으로 테스트가 증가함에 따라 테스트 덕분에 동작을 변경하지 않고 유지해야하는 경우 개체 모델의 상당 부분을 다시 작성할 수 있습니다. 시스템에 대한 변하지 않는 진실을 테스트 하므로 로컬 및 절대 최대 값 모두에서 유효해야합니다.

TDD와 관련된 문제에 관심이 있다면 내가 자주 생각하는 세 가지 다른 문제를 언급 할 수 있습니다.

1. 완전성 문제 : 완전히 시스템을 설명하는 데 필요한 얼마나 많은 테스트? "예제 별 코딩"이 시스템을 설명하는 완전한 방법입니까?

2. 경화 문제 :에 인터페이스를 테스트 무엇이든은, 변경할 수없는 인터페이스를 가질 필요가있다. 테스트는 변하지 않는 진실을 나타냅니다 . 기억하십시오. 불행히도 이러한 진실은 우리가 작성하는 대부분의 코드에 대해 전혀 알려지지 않았으며, 외부 대면 객체에 대해서만 잘 알려져 있습니다.

3. 시험 손상 문제 : 검증 주장을하기 위해, 우리는 (예를 들어, 적은 확대됨)을 쓰기 차선 코드를해야 할 수도 있습니다. 코드를 최대한 잘 작성하기 위해 테스트를 작성하는 방법은 무엇입니까?

주석 처리를 위해 편집 : 리팩토링을 통해 "이중"기능에 대한 로컬 최대 값을 사용하는 예는 다음과 같습니다.

테스트 1 : 입력이 0이면 0을 반환

이행:

function double(x) {
  return 0; // simplest possible code that passes tests
}

리팩토링 : 필요하지 않음

테스트 2 : 입력이 1이면 2를 반환

이행:

function double(x) {
  return x==0?0:2; // local maximum
}

리팩토링 : 필요하지 않음

테스트 3 : 입력이 2이면 4를 반환

이행:

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

리팩토링 :

function double(x) {
  return x*2; // new maximum
}

수학적 용어로 설명하는 것은 우리 자신을 모퉁이에 그리는 것입니다. 이 발생은 TDD에만 적용되는 것이 아닙니다. 폭포수에서는 몇 달 동안 요구 사항을 모으고 쏟아 부을 수 있습니다. 세계 최대를 볼 수 있고 다음 언덕 위에 더 좋은 아이디어가 있음을 깨닫기를 바랍니다.

차이점은이 시점에서 완벽 할 것으로 예상되지 않는 민첩한 환경에서 이전 아이디어를 버리고 새로운 아이디어로 전환 할 준비가 된 것 이상입니다.

TDD에 더 구체적으로, TDD에 기능을 추가 할 때 이런 일이 발생하지 않도록하는 기술이 있습니다. 그것은의 변환 우선 순위 전제 . TDD가 공식적으로 리팩터링 할 수있는 방법 인 경우 기능을 추가하는 공식적인 방법입니다.

에 그의 대답 , @Sklivvz 설득력 문제가 존재하지 않는다고 주장했다.

나는 그것이 중요하지 않다고 주장하고 싶다 : 일반적인 반복 방법론의 기본 전제 (및 raison d' être)와 Agile, 특히 TDD는 글로벌 최적뿐만 아니라 로컬 최적도 아니라는 것입니다. ' 알려진. 다시 말해서, 그것이 문제가 되더라도, 어쨌든 반복적 인 방법으로 그것을 할 수있는 방법은 없습니다. 기본 전제를 ​​수락한다고 가정합니다.

TDD 및 Agile 사례는 최적의 솔루션을 생산할 수 있습니까? (또는 "좋은"솔루션입니까?)

정확히. 그러나 그것은 그들의 목적이 아닙니다.

이러한 방법은 단순히 한 상태에서 다른 상태로 "안전한 통과"를 제공하여 변경이 시간이 걸리고 어렵고 위험하다는 것을 인정합니다. 그리고 두 가지 관행의 핵심은 응용 프로그램과 코드가보다 빠르고 정기적으로 요구 사항을 충족 할 수 있도록 실행 가능하고 입증 된 것입니다.

... [TDD]는 요구 사항을 충족시키는 것으로 입증되지 않은 소프트웨어를 추가 할 수있는 소프트웨어 개발에 반대합니다 ... 2003 년 TDD는 단순함을 장려 한다고 기술을 개발 또는 '재발견'한 것으로 알려진 Kent Beck 자신감을 갖고 디자인합니다. ( 위키 백과 )

TDD는 코드의 각 "청크"가 요구 사항을 충족시키는 데 중점을 둡니다. 특히, 코딩이 열악하여 요구 사항을 이끌어내는 것과 대조적으로 코드가 기존 요구 사항을 충족하도록 보장합니다. 그러나 구현이 어떤 방식 으로든 "최적"이라고 약속하지는 않습니다.

애자일 프로세스의 경우 :

작업 소프트웨어는 진행의 주요 척도입니다 ... 각 반복이 끝날 때마다 이해 관계자와 고객 담당자는 투자 수익을 최적화하기 위해 진행 상황을 검토하고 우선 순위를 다시 평가합니다 ( Wikipedia )

민첩성은 최적의 솔루션을 찾지 않습니다 . 단지 작업 솔루션 - 최적화의 의도와 ROI를 . 그것은 나중에 보다 빨리 작동하는 솔루션을 약속합니다 . "최적의"것이 아닙니다.

그러나 문제 는 잘못 되었기 때문 입니다.

소프트웨어 개발에있어 최적은 애매하고 움직이는 목표입니다. 요구 사항은 일반적으로 유동적이며 보스의 보스로 가득 찬 회의실에서 당황 스러울 정도로 비밀이 가득합니다. 또한 솔루션 아키텍처 및 코딩의 "내재적 장점"은 동료와 경영진의 의견에 따라 분류되고 주관적인 의견에 따라 등급이 매겨집니다.

적어도에서, TDD와 민첩한 관행 어려움을 인정하고 두 가지 최적화를 시도 하다 객관적이고 측정 : . 근무 V하지-작업 과 머지 절 나중에..

또한 객관적인 지표로 "작업 중"및 "수퍼"가 있다고해도이를 최적화 할 수있는 능력은 주로 팀의 기술과 경험에 달려 있습니다.

노력으로 최적의 솔루션을 생산할 때 해석 할 수있는 사항은 다음 과 같습니다.

• SOLID 원칙
• 깨끗한 코드
• 디자인 패턴
• 숙련되고 숙련 된 직원 채용 ...

기타..

_{이러한 것들 각각이 실제로 최적의 솔루션을 생산 하는지 여부 는 또 다른 좋은 질문입니다.}

지금까지 아무도 추가하지 않은 한 가지는 설명하는 "TDD 개발"이 매우 추상적이고 비현실적이라는 것입니다. 알고리즘을 최적화하는 수학적 응용 프로그램에서와 비슷하지만 대부분의 코더가 작동하는 비즈니스 응용 프로그램에서는 그다지 많지 않습니다.

실제 테스트는 기본적으로 비즈니스 규칙을 실행하고 검증합니다.

예를 들어, 고객이 아내와 두 명의 자녀를 둔 30 세의 비 흡연자 인 경우 보험료 카테고리는 "x"입니다.

당신은 매우 오랫동안 정확하고 응용 프로그램이 작동하는 동안 거의 확실하지 않을 때까지 프리미엄 계산 엔진을 반복적으로 변경하지 않을 것입니다.).

실제로 생성 한 것은 특정 범주의 고객에 대해 새 계산 방법을 추가 할 때 모든 기존 규칙이 갑자기 중단되지 않고 잘못된 답변을 제공 할 수있는 안전망입니다. 디버깅의 첫 번째 단계가 버그를 수정하기 위해 코드를 작성하기 전에 오류를 재현하는 테스트 (또는 일련의 테스트)를 작성하는 것이 안전망이 훨씬 더 유용합니다. 그런 다음 누군가가 실수로 원래 버그를 다시 생성하면 코드가 체크인되기 전에 유닛 테스트가 중단됩니다. 예, TDD가 허용하는 한 가지는 큰 리팩토링과 깔끔한 ​​작업을 자신감있게 수행 할 수 있다는 것입니다. 그러나 그것은 당신의 일의 큰 부분이되어서는 안됩니다.

나는 그것이 방해가된다고 생각하지 않는다. 대부분의 팀에는 화이트 보드에 작성한 경우에도 최적의 솔루션을 제공 할 수있는 사람이 없습니다. TDD / Agile은 방해가되지 않습니다.

많은 프로젝트가 최적의 솔루션을 필요로하지 않으며, 필요한 프로젝트, 필요한 시간, 에너지 및 초점이이 분야에서 이루어질 것입니다. 다른 모든 것들과 마찬가지로 먼저 구축하려는 경향이 있습니다. 그럼 빨리 해 퍼포먼스가 그토록 중요하다면 일종의 프로토 타입으로 이것을 할 수 있고 많은 반복을 통해 얻은 지혜로 모든 것을 재구성 할 수 있습니다.

여러 테스트 사례를 구현 한 시나리오를 생각하고 있으며 다음 테스트 사례에는 경쟁 방식이 다른 접근 방식이 필요하다는 것을 알았습니다. 이전 작업을 버리고 다시 시작해야합니다.

이런 일이 발생할 수는 있지만 응용 프로그램의 복잡한 부분이 변경 될 우려가 있습니다. 테스트를하지 않으면이 영역에서 더 큰 두려움이 생길 수 있습니다. TDD의 장점 중 하나는 테스트 스위트를 사용하면이 시스템을 변경해야한다는 개념으로 구축 한 것입니다. 이 모 놀리 식 최적화 솔루션을 처음부터 생각해 보면 변경하기가 매우 어려울 수 있습니다.

또한 이것을 최적화 부족에 대한 우려의 맥락에 두십시오. 성능에 너무 중점을 두었으므로 필요하지 않은 것을 최적화하고 융통성없는 솔루션을 만드는 데 시간을 할애 할 수는 없습니다.

"로컬 최적"과 같은 수학적 개념을 소프트웨어 디자인에 적용하는 것은 속일 수 있습니다. 이러한 용어를 사용하면 소프트웨어 개발 사운드가 실제보다 훨씬 정량적이고 과학적입니다. 코드에 대해 "최적화"가 존재하더라도 코드를 측정 할 방법이 없으므로 코드에 도달했는지 알 수 없습니다.

민첩한 움직임은 소프트웨어 개발이 수학적 방법으로 계획되고 예측 될 수 있다는 믿음에 반하는 반응이었습니다. 더 좋든 나쁘 든 소프트웨어 개발은 ​​과학보다는 기술과 비슷합니다.