주요 리팩토링을 수행 할 때 TDD를 수행하는 사람들이 작업 손실을 처리하는 방법

잠시 동안 나는 코드에 대한 단위 테스트 작성을 배우려고 노력했다.

처음에는 실패한 테스트를 먼저 작성할 때까지 코드를 작성하지 않는 진정한 TDD를 시작했습니다.

그러나 최근에 많은 코드와 관련된 해결하기 어려운 문제가있었습니다. 테스트를 작성하고 코드를 작성하는 데 몇 주를 소비 한 후, 전체 접근 방식이 작동하지 않는다는 불행한 결론에 이르렀고 2 주 동안의 작업을 중단하고 다시 시작해야했습니다.

이것은 방금 코드를 작성했을 때 결정하기에 충분하지 않은 결정이지만, 수백 단위 테스트를 작성했을 때 모든 것을 버리는 것이 더 감정적으로 어려워집니다.

개념 증명을 위해 코드를 조합 한 다음 나중에 접근 방식에 만족하면 나중에 테스트를 작성할 수있을 때 테스트를 작성하는 데 3 ~ 4 일의 노력을 낭비했다고 생각할 수 없습니다.

TDD를 연습하는 사람들은 그러한 상황을 어떻게 올바르게 처리합니까? 어떤 경우에는 규칙을 구부리는 경우가 있습니까? 아니면 코드가 쓸모없는 것으로 판명 될 때에도 항상 테스트를 먼저 슬레이브로 작성합니까?

여기에 두 가지 문제가 있다고 생각합니다. 첫 번째는 원래 디자인이 최선의 방법이 아닐 수도 있다는 사실을 미리 알지 못했다는 것입니다. 이것을 미리 알고 있다면, 빠른 던지기 프로토 타입 을 개발 하거나 가능한 디자인 옵션을 탐색하고 가장 유망한 방법을 평가하기 위해 선택했을 수 있습니다. 프로토 타이핑에서는 프로덕션 품질 코드를 작성할 필요가 없으며 코드를 연마하는 것이 아니라 학습에만 중점을두기 때문에 모든 구석 구석에 대한 단위 테스트가 필요하지 않습니다.

이제 프로덕션 코드 개발을 바로 시작하기보다는 프로토 타입 및 실험이 필요하다는 것을 깨닫는 것이 항상 쉬운 것은 아니며 항상 가능한 것은 아닙니다. 방금 얻은 지식으로 무장하면 다음에 프로토 타이핑의 필요성을 인식 할 수 있습니다. 아니면 아닐 수도 있습니다. 그러나 최소한이 옵션을 고려해야한다는 것을 알고 있습니다. 그리고 이것은 그 자체로 중요한 지식입니다.

다른 문제는 당신의 인식과 IMHO입니다. 우리 모두는 실수를 저지르고, 우리가 다르게해야했던 일을 회상하면 쉽게 알 수 있습니다. 이것은 우리가 배우는 방식입니다. 프로토 타이핑이 중요 할 수있는 학습 가격으로 단위 테스트에 대한 투자를 기록하고 극복하십시오. 같은 실수를 두 번하지 않도록 노력하십시오 :-)

TDD의 요점은 이 문제를 피하기 위해 작은 함수로 작은 증분 코드를 작성해야한다는 것 입니다. 한 도메인에서 코드를 작성하는 데 몇 주를 보냈고 아키텍처를 다시 생각할 때 작성한 모든 단일 유틸리티 메소드 가 쓸모 없게된다면, 처음에는 메소드가 너무 커질 것입니다. (예, 이것이 지금 rght를 위안하지는 않습니다.)

브룩스는 "일단 버릴 계획이다. 당신이 그렇게하고있는 것 같습니다. 즉, 코드 단위가 아닌 코드 단위를 테스트하기 위해 단위 테스트를 작성해야합니다. 이것들은 더 기능적인 테스트이므로 내부 구현에 대해 테스트해야합니다.

예를 들어, PDE (부분 미분 방정식) 솔버를 작성하려면 수학적으로 해결할 수있는 문제를 해결하기 위해 몇 가지 테스트를 작성합니다. 이것들은 저의 첫 번째 "단위"테스트입니다. 읽기 : 기능 테스트는 xUnit 프레임 워크의 일부로 실행됩니다. PDE를 해결하는 데 사용하는 알고리즘에 따라 변경되지 않습니다. 내가 신경 쓰는 것은 결과입니다. 두 번째 단위 테스트는 알고리즘을 코딩하는 데 사용되는 함수에 중점을 두므로 Runge-Kutta와 같이 알고리즘에 따라 다릅니다. Runge-Kutta가 적합하지 않다는 것을 알게 되더라도 여전히 최상위 수준 테스트 (Runge-Kutta가 적합하지 않다는 것을 포함하여)를 테스트하게됩니다. 따라서 두 번째 반복에는 여전히 첫 번째와 동일한 테스트가 많이 있습니다.

문제는 아마도 코드에 의한 것이 아니라 디자인상의 문제 일 수 있습니다. 그러나 자세한 내용이 없으면 말하기가 어렵습니다.

TDD는 반복적 인 프로세스라는 것을 명심해야합니다. 작은 테스트를 작성하고 (대부분의 경우 몇 줄이면 충분합니다) 실행하십시오. 테스트가 실패해야합니다. 이제 기본 소스에서 직접 작업하고 테스트를 통과하도록 테스트 된 기능을 구현하십시오. 이제 다시 시작하십시오.

모든 테스트를 한 번에 작성하려고 시도하면 안됩니다. 알다시피이 방법으로 문제가 해결되지는 않습니다. 이렇게하면 사용하지 않을 테스트 작성에 시간을 낭비 할 위험이 줄어 듭니다.

나는 당신이 스스로 그것을 말했다 : 당신은 모든 단위 테스트를 작성하기 전에 접근 방식에 대해 확신하지 못했습니다.

내가 이론적으로 배운 것과 실제 TDD 프로젝트 (실제로 3 년 동안 2 년 동안 일한 3 명 만)를 비교하면서 배운 것은 자동 테스트! = 단위 테스트 (물론 상호간에 상관없이) 독특한).

다시 말해서, TDD의 T는 U와 함께 U를 가질 필요가 없습니다. 자동화되어 있지만 자동화 된 기능 테스트보다 단위 테스트 (단위 및 방법 테스트와 동일)가 적습니다. 같은 수준입니다. 현재 작업중인 아키텍처로서 기능 세분성. 몇 번의 테스트와 기능적인 큰 그림만으로 높은 수준으로 시작 하면 결국 수천 개의 UT와 아름다운 아키텍처로 잘 정의 된 모든 수업으로 끝납니다 ...

단위 테스트는 팀에서 작업 할 때 끝없는 버그 사이클을 생성하는 코드 변경을 피하기 위해 많은 도움을줍니다. 그러나 각 사용자 스토리에 대해 최소한 글로벌 작업 POC를 갖기 전에 프로젝트 작업을 시작할 때 너무 정확한 것을 쓰지 않았습니다.

어쩌면 그것은 내 개인적인 방법 일 것입니다. 프로젝트에서 어떤 패턴이나 구조를 처음부터 결정할지 충분한 경험이 없으므로 처음부터 100 개의 UT를 작성하는 데 시간을 낭비하지 않습니다 ...

더 일반적으로 모든 것을 깨뜨리고 그것을 던지는 아이디어는 항상 거기에 있습니다. 우리가 도구와 방법을 사용하려고 할 때 "연속적"으로, 때때로 엔트로피와 싸우는 유일한 방법은 다시 시작하는 것입니다. 그러나 목표는 이러한 상황이 발생할 때 구현 한 자동화 및 단위 테스트를 통해 프로젝트가없는 경우보다 이미 비용이 적게 들고 평형을 찾으면 프로젝트 비용이 줄어든다는 것입니다.

TDD를 연습하는 사람들은 그러한 상황을 어떻게 올바르게 처리합니까?

1. 프로토 타이핑 시점과 코딩 시점을 고려하여
2. 단위 테스트는 TDD와 동일하지 않음을 인식
3. TDD 테스트를 작성하여 기능 단위가 아닌 기능 / 스토리를 검증

단위 테스트와 테스트 중심 개발의 혼동은 많은 고통과 고민의 원천입니다. 다시 한 번 검토하겠습니다.

• 단위 테스트 는 구현 에서 각 개별 모듈과 기능을 확인하는 것과 관련이 있습니다 . UT에서는 코드 커버리지 메트릭 및 매우 빠르게 실행되는 테스트와 같은 것에 중점을 둡니다.
• 테스트 중심 개발 은 요구 사항의 각 기능 / 스토리를 검증하는 것과 관련이 있습니다 . TDD에서는 먼저 테스트를 작성하고 작성된 코드가 의도 한 범위를 초과하지 않도록하고 품질에 대한 리팩토링과 같은 사항에 중점을 둡니다.

요약하자면, 단위 테스트에는 구현 초점이 있고 TDD에는 요구 사항 초점이 있습니다. 그들은 같은 것이 아닙니다.

테스트 중심 개발은 개발을 추진 하기위한 것입니다. 작성하는 테스트는 현재 작성중인 코드의 정확성을 확인하고 첫 번째 줄부터 개발 속도를 높이는 데 도움이됩니다.

당신은 테스트가 부담이며 나중에 점진적인 개발만을위한 것이라고 생각하는 것 같습니다. 이 사고 방식은 TDD와 일치하지 않습니다.

정적 타이핑과 비교할 수 있습니다. 정적 타입 정보를 사용하지 않고 코드를 작성할 수 있지만 정적 타입을 코드에 추가하면 코드의 특정 속성을 확인하고 마음을 자유롭게하고 대신 중요한 구조에 집중할 수 있으므로 속도와 속도가 향상됩니다. 효능.

주요 리팩토링을 할 때의 문제점은 당신이 씹을 수있는 것보다 더 많이 물린 것을 깨닫게하는 길을 따라갈 수 있다는 것입니다. 거대한 리팩토링은 실수입니다. 시스템 설계에 처음 결함이있는 경우 리팩토링은 어려운 결정을 내리기 전에 지금까지만 걸릴 수 있습니다. 시스템을 그대로두고 문제를 해결하거나 재 설계 및 주요 변경을 계획하십시오.

그러나 다른 방법이 있습니다. 코드 리팩토링의 실질적인 이점은 일을 더 단순하고 읽기 쉽고 유지 관리하기 쉽게 만드는 것입니다. 불확실성이있는 문제에 접근하면 변경 사항을 급증하고 문제에 대해 자세히 알아보고 급증을 버리고 급증 내용을 기반으로 새로운 리팩터링을 적용하기 위해 지금까지 어디로 갈 수 있는지 확인하십시오. 가르쳤다. 문제는 단계가 적고 리팩토링 노력이 테스트를 먼저 작성하는 능력을 초과하지 않으면 확실하게 코드를 실제로 향상시킬 수 있다는 것입니다. 해결책은 분명해 보일 수 있으므로 테스트를 작성한 다음 코드를 작성하고 코드를 더 작성하는 것이 유혹이지만 변경 사항이 더 많은 테스트를 변경한다는 사실을 곧 깨닫게되므로 한 번에 한 가지만 변경하도록주의해야합니다.

따라서 리팩토링을 주요 리팩토링으로 만들지 마십시오. 걸음마. 방법을 추출하여 시작한 다음 중복 제거를 찾으십시오. 그런 다음 클래스 추출로 이동하십시오. 각각 작은 단계로 한 번에 하나의 작은 변화가 있습니다. 코드를 추출하는 경우 먼저 테스트를 작성하십시오. 코드를 제거하는 경우 코드를 제거하고 테스트를 실행하고 깨진 테스트가 더 이상 필요한지 결정하십시오. 한 번에 하나의 작은 아기 발걸음. 시간이 더 걸리는 것처럼 보이지만 실제로 리팩토링 시간이 상당히 단축됩니다.

그러나 현실적으로는 모든 스파이크가 잠재적 인 노력 낭비로 보인다. 코드 변경 사항은 아무데도 나타나지 않으며 자신의 코드를 코드에서 복원하는 경우가 있습니다. 이것은 우리가 매일하는 일의 현실입니다. 그러나 실패한 모든 스파이크가 무언가를 가르치면 낭비되지 않습니다. 실패하는 모든 리팩토링 노력은 너무 빨리 수행하려고하거나 접근 방식이 잘못되었을 수 있음을 알려줍니다. 그것으로부터 무언가를 배우면 시간 낭비가 아닙니다. 이 일을 많이할수록 더 많이 배우고 더 효율적으로 할 수 있습니다. 저의 조언은 지금 당장 착용하고, 더 적게함으로써 더 많은 것을 배우고, 이것이 당신을 어디로 인도하기 전에 스파이크를 얼마나 멀리해야하는지 파악할 때까지는 아마도 필요한 방법임을 인정하는 것입니다.

3 일 후에 접근 방식에 결함이있는 이유는 확실하지 않습니다. 아키텍처의 불확실성에 따라 테스트 전략 변경을 고려할 수 있습니다.

• 성능에 대해 확실하지 않은 경우 성능을 주장하는 몇 가지 통합 테스트로 시작 하시겠습니까?

• API의 복잡성이 당신이 조사하는 것이라면, 실제로 진행되는 작은 단위 테스트를 작성하여 가장 좋은 방법을 찾으십시오. 아무것도 구현하는 것을 귀찮게하지 말고 클래스가 하드 코딩 된 값을 반환하거나 NotImplementedExceptions를 throw하도록하십시오.

저에게 단위 테스트는 또한 인터페이스를 "실제"로 사용하는 기회이기도합니다 (단위 테스트만큼이나 실용적입니다!).

테스트를 강요 받으면 디자인을 연습해야합니다. 이것은 일을 제정신 상태로 유지하는 데 도움이됩니다 (무엇이 너무 복잡해서 테스트를 작성하는 것이 부담이된다면 사용하는 방법은 무엇입니까?).

이것은 디자인의 변경을 피하는 것이 아니라 디자인의 필요성을 드러냅니다. 그렇습니다. 완전한 재 작성은 고통입니다. 피하기 위해 (일반적으로 파이썬에서 (C ++의 최종 개발로)) 일반적으로 하나 이상의 프로토 타입을 설정했습니다.

물론, 당신은 항상이 모든 케이크에 대한 시간이 없습니다. 사람들은 정확하게 당신이 필요합니다 때 경우 LARGER 목표를 달성하기 위해 시간의 양을 ... 및 / 또는 통제하에 모든 것을 유지.

창의적인 개발자 서커스에 오신 것을 환영합니다 .

처음에 코딩하는 모든 '법적 / 합리적인'방법을 존중하는 대신 직관을
시도하십시오 . 무엇보다 중요하고 새로운 것이 아니라 원하는 샘플이없는 경우 : -이미 알고있는 것에서 본능으로 작성하십시오. 당신의 정신과 상상력이 아닙니다. -그만해 -돋보기를 사용하여 작성한 모든 단어를 검사하십시오. "텍스트"가 문자열에 가깝기 때문에 "텍스트"를 쓰지만 "동사", "형용사"또는 더 정확한 것이 필요합니다. 다시 읽고 새로운 의미로 방법을 조정하십시오 . 또는 미래에 대해 생각하는 코드를 작성 했습니까? 그것을 제거 -올바른 작업, 다른 작업 (스포츠, 문화 또는 기타 비즈니스 이외의 일)을 수행하고 다시 와서 다시 읽으십시오. -모두 잘 맞습니다







-수정하고 다른 작업을 수행 한 후 다시 읽고 다시 읽습니다.
-모두 잘 맞고 TDD로 전달
-이제 모두 정확하고 좋습니다
-벤치마킹하여 최적화 할 사항을 지적하십시오.

표시되는 내용 :
-모든 규칙을 준수하는 코드를 작성했습니다
.-경험, 새로운 업무 방식,
마음의 변화 등 새로운 구성을 두려워하지 않습니다.

그리고 지금, 위와 같은 UML이 보이면
"Boss, TDD로 시작합니다 ...." 라고 말할 수 있습니다 .
이것은 또 다른 새로운 것입니까?
"보스, 내가 코딩하는 방식을 결정하기 전에 무언가를 시도 할 것이다."

PARIS
Claude