13

테스트 중심 개발을 실험하고 있는데 종종 다음과 같은 상황에 처한다는 것을 알았습니다.

일부 기능 X에 대한 테스트를 작성합니다. 해당 테스트는 실패합니다.
X를 구현하려고 할 때 코드의 하위 계층에 일부 기능 Y를 구현해야 함을 알았습니다. 그래서...
Y에 대한 테스트를 작성합니다. 이제 X 및 Y에 대한 테스트가 모두 실패합니다.

한 번에 서로 다른 코드 레이어에서 4 가지 기능을 사용하면 실제로 수행중인 작업 (동시에 너무 많은 테스트가 실패 함)에 집중하지 못했습니다.

테스트 작성을 시작하기 전에도 작업을 계획하는 데 더 많은 노력을 기울여이 문제를 해결할 수 있다고 생각합니다. 그러나 어떤 경우에는 하위 계층의 API를 잘 모르기 때문에 더 깊이 들어가야한다는 것을 알지 못했습니다.

그런 경우 어떻게해야합니까? TDD에 권장 사항이 있습니까?

language-agnostic tdd

— 리 오리
소스

9

좋은 점은 테스트중인 코드에 도움이 필요하다는 것입니다. 인터페이스를 즉시 구현하는 대신 인터페이스를 만들고 모의를 사용하여 테스트가 올바른 코드에 태그를 지정하는지 확인하십시오. 테스트를 통과 한 후에는 테스트가 의존하는 코드를 구현할 수 있습니다.

— 마이클 브라운
소스

내 테스트에는 일반적으로 메소드가 내부적으로 수행해야 할 작업에 대한 지식이 없습니다 (저급 API 호출). 테스트 된 코드에서 필요한 것을 조롱하기 위해 테스트를 조정해야합니까?

— liori

2

마찬가지로, 테스트 된 클래스는 '더 낮은 레이어'가하는 일을 신경 쓰지 않아야합니다. 실제 클래스 / 객체 대신 모의 객체 / 스텁을 사용하십시오. 이를 위해서는 디자인에 약간의 노력이 필요할 수 있지만 결합이 적고 재사용하기 쉬운 코드가 생성됩니다.

— Mchl

1

의존성 주입을 사용하고 있습니까? 이렇게하면 하위 수준의 우려를 상위 수준의 클래스에서 쉽게 분리 할 수 있습니다. 테스트중인 클래스에는 테스트에서 인터페이스에 대한 모의 객체를 만드는 인터페이스에 대한 매개 변수가있는 생성자가 있습니다. 기본적으로 이미 하위 수준 서비스를 구현 한 것처럼 가장하고 있습니다.

— Michael Brown

@Mike Brown, 그렇습니다. 모의 객체를 만들 수 있다는 것을 알고 있습니다. 그러나 기능 테스트에서 X나는 의존성의 어떤 부분 X을 조롱 해야하는지 알아야합니다 . 나는 이것이 구현 세부 사항의 일부라고 생각합니다. 테스트의 일부가되어서는 안됩니다. 그렇지 않으면 구현을 리팩토링하면서 테스트를 변경해야 할 수도 있습니다. 그것에 대해 걱정해야합니까?

— liori

1

전혀 ... 테스트는 테스트중인 시스템의 가정을 반영해야합니다. 또한 시스템이 의존하는 서비스에서 필요한 것을 노출시키는 데 도움이됩니다. 나는이 문제에 대해 당신과 동의했지만 재귀 프로그래밍을 이해하는 방법과 비교합니다. 먼저 원하는 것을 수행하는 함수가 있다고 가정하여 코드를 작성하십시오. 그런 다음 원하는 것을 수행하는 코드를 작성하십시오.

— Michael Brown

4

스텁 및 모의 객체를 사용하여 아직 수정 / 구현되지 않은 기능을 시뮬레이션 할 수 있습니다. 또한 이러한 종류의 '연쇄 반응'을 유발하는 종속성을 해결하는 데 도움이 될 수 있습니다.

반면에 다음 변경을 주도하는 하나의 (실패한) 테스트 만 유지하는 것이 최선의 방법입니다.

새로운 기능에 의존하는 코드를 대상으로하는 다른 테스트는이 시점에서 실제로 관련이 없기 때문에 용어 적으로 비활성화 할 수 있습니다. 귀하의 경우 Y 등을 구현할 때까지 X 테스트를 비활성화하십시오.

그렇게하면 다음 변경에만 집중할 수 있습니다. 원하는 것입니다.

— Ratkok
소스

하, IDE 내에서 테스트를 실행하는 동안 테스트를 끄는 기능을 찾았지만 찾지 못했습니다. 이제 파이썬이 unittest이미 테스트 건너 뛰기를 발견했습니다 . 이것으로 충분할 것입니다.

— liori

Google 테스트 C ++ 프레임 워크를 사용하며 테스트를 비활성화 할 수있는 옵션이 있습니다. 비활성화 된 테스트는 실행되지 않고 컴파일됩니다-필요한 순간-실행할 준비가되었습니다 (또한 비활성화 된 테스트의 '강제 실행'- '런타임 인 에이블'종류)-뛰어난 기능 ...

— ratkok

3

중지

여기서는 두 가지 별도의 문제가있는 것처럼 보입니다.

몇 가지 이야기와 테스트 시나리오를 잊어 버렸으며 특정 테스트 시나리오에서 작업을 시작하기 전까지는 발견하지 못했습니다.
실제로 TDD 기능 테스트가 아닌 단위 테스트를 수행하고 있습니다.

# 1의 경우을 중지 하고 돌아가서 스토리 및 테스트 시나리오를 업데이트 한 후 다른 시나리오로 다시 시작하십시오.

# 2의 경우을 중지 하고 단위가 아닌 기능을 테스트하고 있다는 것을 기억하십시오. 따라서 다른 인터페이스를 능숙하게 조롱하거나 새로운 테스트 시나리오 를 추가 하지 않고 테스트를 통과시키기 위해 더 많은 코드를 구현하십시오 . 이것은 테스트 시나리오가 빠진 것이 아니라 대신 단위 테스트와 TDD를 병합하는 것으로 가정합니다.

— 스티븐 에이 로우
소스

나는 당신의 대답을 정말로 좋아합니다. 실제로 일어나는 일을 설명하는 것이 더 좋습니다.

— maple_shaft

... 그 말을 듣고 나는 "STOP, 우리는 역 추적 할 필요가있다"는 구절에서 마음을 완전히 잃지 않을 세계의 PM을 모른다. 그들은 프로젝트를 계속 진행하기 위해 제단에서 처음 태어난 것을 희생하지 않고 모든 것을 시도 할 것이며, 기술 부채와 불완전한 단위 테스트는 저주받을 것입니다. 조직의 유일한 지표가 프로젝트를 제 시간에 끝내고있을 때 당신을 비난 할 수 없다고 생각합니다. 일부 조직은 품질보다 시간을 중요하게 생각하기 때문에 이러한 유형의 조직에서 TDD가 성공적으로 작동하는 것을 보지 못했을 것입니다. 불행히도 대부분 IMO입니다.

— maple_shaft

@maple_shaft : 다시 그룹화를 중단하는 시간은 몇 시간이 될 수 있습니다. 프로세스가 방해가되지 않는 한, 며칠 동안 멈 추면 다시 정상으로 돌아올 수 있습니다. 프로젝트는 성공할 것입니다. 잘못된 길을 따라 완전히 증기를 밟을 필요는 없습니다!

— Steven A. Lowe

0

이것은 TDD와 함께 나에게 큰 질문이자 큰 좌절입니다. 이 시나리오에서는 개발을 시작할 때까지 필요한 하위 구성 요소 나 기능을 알 수있는 방법이없는 TDD가 부족하다고 생각합니다.

개인적으로 TDD는 기능을 수행하기 위해 수행해야 할 작업과 호출해야 할 작업을 정확히 알고있는 경우에만 작동합니다. 개발자가 시작하기 전에 항상 모든 것을 알고있는 것은 아니므로 본인이 설명하는 바로 그 상황을 완화 할 수있는 가장 좋은 방법은 다음과 같습니다.

원기

기술적 인 문제에 대한 방법과 접근 방식을 탐색하고 발견하기 위해 간단한 프로토 타입 앱을 만들면 많은 레그 작업을 발견하고 시작하기 전에 연구를 중단합니다. 설계 및 추정도 훨씬 쉬워졌습니다.

프로토 타입이 응용 프로그램이되기 위해 너무 관여해야한다면 게으른 일을하지 말고 사실 이후 프로토 타입에 대한 단위 테스트를 작성하라고 강력히 권합니다.

이 시점에서 하위 수준 API에 대해 자세히 알고 상위 수준 구성 요소에서 하위 수준 API를 성공적으로 조롱 할 수 있어야합니다.

— maple_shaft
소스

따라서 실제로는 비공식적 (= 공식적인 방법론을 따르지 않음) 방식으로 탐색 코딩을 수행하여 계획 단계에 대한 추가 정보를 얻을 것을 제안합니다. 그런 다음 실제 코드를 계획하기에 충분한 정보를 제공한다고 가정하십시오. 내가 맞아?

— liori

프로토 타이핑이 비공식적 인 프로세스라고 생각하는 이유는 무엇입니까? 모든 견적은 프로토 타이핑을 설명하고 프로젝트 일정은 필요한 개발 작업뿐만 아니라 프로토 타입도 고려해야합니다. 나는 그것을 Design 또는 Code-Review와 동일하게 본다. 이 노트에는 공식화되어 있으며 알려지지 않은 많은 작업에 대해 더 자세히 설명해야합니다. 프로토 타이핑과 개념 증명을 수행 할 수있는 능력이 없다면 TDD를 추구하는 것은 개발자가 모든 기능을 가진 모든 것에 대해 모든 것을 알고 있다고 가정합니다. 현실 세계는 그런 식으로 작동하지 않으며 나는 당신이 얼마나 똑똑하거나 경험이 있는지 상관하지 않습니다.

— maple_shaft

"비공식적 인 방식"이란 프로토 타입 제작 시간을 고려해서는 안된다는 것을 의미하지는 않지만 프로토 타입을 제작하는 동안 TDD 나 다른 코드 방법론을 따르지 않습니다.

— liori

TDD는 단위 테스트 및 개발 방법론입니다. 코드 검토를 위해 TDD를 수행하는 것이 합리적입니까? TDD가 디자인, 기술 사양 작성 또는 화이트 보드 작성에 적합합니까? 프로토 타이핑은 연구, 개념 증명 및 교육을위한 탐구 적 개발 유형 자체의 작업입니다.

— maple_shaft

1

TDD는 만드는 완벽한 프로토 타입에 적합한. 이를 통해 반복 가능한 실행 요구 사항의 형태로 원하는대로 사물 (기능, API, 전체 프로그램)을 신속하게 노출 할 수 있습니다. 테스트를 통해 성장하는 객체 지향 소프트웨어 가이드를 읽으십시오 . 테스트 우선 방식으로 전체 애플리케이션 (통합 포함)을 빌드하는 단계를 안내합니다.

— Frank Shearar

0

TDD를 수행하는 동안 작문 시험의 종류에 따라 다릅니다.

고전적인 모델은 단위 테스트를 작성하고 모의 또는 스터브를 사용하여 다른 "단위"코드에서 테스트를 분리하는 것입니다.

전체 스택 또는 거의 전체 스택 테스트를 테스트하는 ATDD와 같은 다른 대안 모델이 많이 있습니다. 이 특정한 경우에는 단일 코드 단위가 아닌 필요한 프로그램 동작을 주장하는 필기 테스트이므로 다른 테스트를 작성하지 않을 것입니다. 테스트를 충족시키기 위해 구현에 왕복이 필요합니다. 그런 다음 다른 기능 / 동작에 대한 다른 테스트를 추가하십시오.

— 다이어트
소스

TDD, 이전 테스트는 아직 구현되지 않은 새로운 테스트

중지