TDD 대 생산성

현재 프로젝트 (C ++ 게임)에서 개발 중 테스트 주도 개발을 100 % 사용하기로 결정했습니다.

코드 품질면에서 이것은 훌륭했습니다. 내 코드는 그렇게 잘 설계되거나 버그가 없었습니다. 나는 프로젝트가 시작될 때 1 년 전에 작성한 코드를 볼 때 울지 않으며, 더 쉽게 테스트 할 수있을뿐만 아니라 구현하고 사용하기가 더 쉬운 것을 구조화하는 방법에 대해 훨씬 더 잘 이해했습니다. .

하지만 ... 프로젝트를 시작한 지 1 년이 지났습니다. 물론, 나는 여가 시간에만 일할 수 있지만 TDD는 내가 익숙한 것에 비해 여전히 나를 늦추고 있습니다. 개발 속도가 느려질수록 시간이 지남에 따라 더 나아진다는 것을 읽었으며, 테스트를 훨씬 더 쉽게 생각했지만 지금은 1 년 동안 해왔으며 여전히 달팽이 속도로 작업하고 있습니다.

작업이 필요한 다음 단계에 대해 생각할 때마다 매번 멈추고 실제 코드를 작성할 수 있도록 테스트를 작성하는 방법에 대해 생각해야합니다. 때로는 작성하려는 코드를 정확히 알고 있지만 테스트로 완전히 커버하기에 충분히 세분화하는 방법을 모르면 몇 시간 동안 고착 될 것입니다. 다른 경우에는 12 가지 테스트를 빠르게 생각하고 작성하는 데 몇 분이 걸리는 작은 실제 코드를 다루기 위해 테스트 작성에 1 시간을 소비합니다.

또는 게임의 특정 엔티티와 게임의 생성 및 사용의 모든 측면을 다루기 위해 50 번째 테스트를 마친 후에는 할 일 목록을보고 코딩 할 다음 엔티티를보고 글을 쓸 때 공포에 빠집니다. 구현하기 위해 또 다른 50 가지 유사한 테스트.

작년의 진전 상황을 살펴보면서 나는 "망할 프로젝트를 끝내기"위해 TDD를 포기하는 것을 고려하고있다. 그러나 코드 품질을 포기하는 것은 내가 기대하는 것이 아닙니다. 테스트 작성을 중단하면 코드를 모듈 식으로 테스트 할 수있는 습관을 잃게 될 것 같습니다.

내가 아직 너무 느리게 잘못된 일을하고 있습니까? 이점을 완전히 잃지 않고 생산성을 높이는 대안이 있습니까? 약간? 테스트 범위가 적습니까? 다른 사람들은 모든 생산성과 동기를 없애지 않고 TDD에서 어떻게 살아남습니까?

당신의 경험을 공유하고 당신의 우려를 표명 해 주셔서 감사하겠습니다.

• 시간 / 생산성 : 테스트 작성은 테스트를 작성하지 않는 것보다 느립니다. 당신이 그것을 범위로한다면, 나는 동의 할 것입니다. 그러나 비 TDD 접근 방식을 적용하는 병렬 노력을 수행하는 경우 기존 코드를 감지하고 디버그하고 수정하는 데 소요되는 시간이 순전히 부정적인 결과를 초래할 수 있습니다. 저에게있어 TDD는 코드 신뢰도에 영향을주지 않으면 서 가장 빠릅니다. 당신의 방법에서 가치를 추가하지 않는 것들을 찾으면 제거하십시오.
• 테스트 횟수 : N 개를 코딩하는 경우 N 개를 테스트해야합니다. 켄트 벡 (Kent Beck)의 라인 중 하나를 의역 " 테스트 당신은 일을 할 것입니다 만. "
• 몇 시간 동안 고착 : 나도 (때로는 라인을 멈추기 전에> 20 분이 지나지 않음). 디자인에 약간의 작업이 필요하다는 것을 알려주는 코드 일뿐입니다. 테스트는 SUT 클래스의 또 다른 클라이언트입니다. 테스트에서 유형을 사용하기 어려운 것으로 판명되면 프로덕션 클라이언트도 마찬가지입니다.
• 비슷한 테스트 tedium : 이것은 반론을 작성하기 위해 더 많은 컨텍스트가 필요합니다. 즉, 그 유사성에 대해 멈추고 생각하십시오. 어떻게 든 그 테스트를 데이터로 구동 할 수 있습니까? 기본 유형에 대한 테스트를 작성할 수 있습니까? 그런 다음 각 파생에 대해 동일한 테스트 세트를 실행하면됩니다. 당신의 시험을 듣습니다. 올바른 게으른 사람이되어 지루함을 피할 수있는 방법을 찾아보십시오.
• 다음에해야 할 일 (테스트 / 사양)에 대해 생각하지 않는 것은 나쁜 일이 아닙니다. 반대로 "올바른 것"을 구축 할 것을 권장합니다. 일반적으로 테스트 방법을 생각할 수 없다면 구현도 생각할 수 없습니다. 구현 아이디어가 나올 때까지 비워 두는 것이 좋습니다. 아마도 YAGNI의 선제 적 설계로 인해 더 간단한 솔루션이 어두워 질 수도 있습니다.

그리고 그것은 최종 질문으로 나에게옵니다 : 어떻게 나아지나요? 내 (또는) 답변은 읽기, 반영 및 연습입니다.

예를 들어, 나는 최근에 탭을 유지

• 내 리듬이 RG [Ref] RG [Ref] RG [Ref]를 반영하는지 아니면 RRRRGRRef입니까?
• 빨간색 / 컴파일 오류 상태에서 보낸 시간 %
• 빨간색 / 깨진 빌드 상태에 갇혀 있습니까?

100 % 테스트 범위는 필요하지 않습니다. 실용적이 되십시오.

TDD는 여전히 나를 상당히 늦추고 있습니다

사실은 거짓입니다.

TDD가 없으면 몇 주 동안 코드를 작성하고 내년에는 "테스트"하고 많은 버그를 수정하는 데 소비합니다.

TDD를 사용하면 실제로 작동하는 코드를 작성하는 데 1 년이 걸립니다. 그런 다음 몇 주 동안 최종 통합 테스트를 수행합니다.

경과 시간은 아마 동일 할 것입니다. TDD 소프트웨어는 실질적으로 더 나은 품질입니다.

또는 게임의 특정 엔티티와 게임의 생성 및 사용의 모든 측면을 다루기 위해 50 번째 테스트를 마친 후에는 할 일 목록을보고 코딩 할 다음 엔티티를보고 글을 쓸 때 공포에 빠집니다. 구현하기 위해 또 다른 50 가지 유사한 테스트.

이것은 TDD의 "리 팩터"단계를 얼마나 따르고 있는지 궁금합니다.

모든 테스트가 통과되면 코드를 리팩터링하고 중복을 제거해야합니다. 사람들은 일반적으로 이것을 기억하지만 때로는 테스트 를 리팩토링하고 복제를 제거하고 사물을 단순화해야 할 때라 는 사실을 잊기도합니다 .

코드 재사용을 위해 두 개의 엔티티가 하나로 병합 된 경우 테스트 병합도 고려하십시오. 실제로 코드의 증분 차이 만 테스트하면됩니다 . 테스트에서 정기적으로 유지 관리를 수행하지 않으면 테스트하기가 어려워 질 수 있습니다.

도움이 될만한 TDD에 대한 몇 가지 철학적 요점 :

• 테스트 작성 경험이 많음에도 불구하고 테스트 작성 방법을 알 수 없으면 코드 냄새 가 분명합니다 . 코드에 모듈성이 부족하여 작고 간단한 테스트를 작성하기가 어렵습니다.
• TDD를 사용할 때 약간의 코드를 스파이 킹하는 것은 완벽하게 허용됩니다. 원하는 코드를 작성하여 모양을 파악한 다음 코드를 삭제하고 테스트를 시작하십시오.
• 나는 운동의 한 형태로 매우 엄격한 TDD를 연습하는 것을 본다. 처음 시작할 때는 반드시 매번 테스트를 먼저 작성하고 가장 간단한 코드를 작성하여 테스트를 통과하십시오. 그러나 연습에 익숙해지면 이것은 필요하지 않습니다. 가능한 모든 단일 코드 경로에 대한 단위 테스트는 없지만 경험을 통해 단위 테스트로 테스트해야 할 사항과 기능 또는 통합 테스트로 다룰 수있는 것을 선택할 수 있습니다. 1 년 동안 TDD를 엄격한 방식으로 연습했다면이 시점에 가깝다고 생각합니다.

편집 : 단위 테스트의 철학 주제에 대해, 나는 이것이 당신에게 흥미로울 것이라고 생각합니다 : The Testivus

더 실용적이지는 않지만 더 실용적이라면 다음을 지적하십시오.

• 개발 언어로 C ++을 언급했습니다. JUnit 및 Mockito와 같은 우수한 라이브러리를 사용하여 Java에서 TDD를 광범위하게 연습했습니다. 그러나 C ++의 TDD는 사용 가능한 라이브러리 (특히 모의 프레임 워크)가 없기 때문에 매우 실망 스럽습니다. 이 시점이 현재 상황에서 큰 도움이되지는 않지만, TDD를 완전히 버리지 전에 고려해야합니다.

매우 흥미로운 질문입니다.

중요한 점은 C ++은 쉽게 테스트 할 수 없으며 일반적으로 게임도 TDD에 매우 나쁜 후보라는 점입니다. OpenGL / DirectX가 드라이버 X에서는 삼각형 빨강을, 드라이버 Y에서는 노랑을 그리는지 테스트 할 수 없습니다. 셰이더 변환 후 범프 맵 법선 벡터가 뒤집 히지 않으면 또한 정밀도가 다른 드라이버 버전의 클리핑 문제도 테스트 할 수 없습니다. 잘못된 호출로 인해 정의되지 않은 드로잉 동작은 정확한 코드 검토 및 SDK를 통해서만 테스트 할 수 있습니다. 소리도 나쁜 후보입니다. 게임에 매우 중요한 멀티 스레딩은 단위 테스트에 거의 쓸모가 없습니다. 힘든 일입니다.

기본적으로 게임은 많은 GUI, 사운드 및 스레드입니다. GUI는 WM_을 보낼 수있는 표준 구성 요소라도 단위 테스트가 어렵습니다.

따라서 테스트 할 수있는 것은 모델 로딩 클래스, 텍스처 로딩 클래스, 매트릭스 라이브러리 및 기타 코드입니다. 많은 코드가 아니며 종종 첫 번째 프로젝트 인 경우 재사용이 불가능합니다. 또한 독점 형식으로 포장되어 있으므로 모딩 도구 등을 해제하지 않으면 타사 입력이 크게 다를 가능성이 거의 없습니다.

다시, 나는 TDD 전문가 또는 전도자가 아니므로, 모든 것을 소금 한 알로 가져 가십시오.

아마도 주요 핵심 구성 요소 (예 : 매트릭스 라이브러리, 이미지 라이브러리)에 대한 테스트를 작성했을 것입니다. abort()모든 기능에 예기치 않은 입력을 추가하십시오 . 그리고 가장 중요한 것은 쉽게 깨지지 않는 내성 / 탄성 코드에 집중하는 것입니다.

하나의 오류로 인해 C ++, RAII를 잘 사용하고 좋은 디자인으로 오류를 예방할 수 있습니다.

기본적으로 게임을 출시하려면 기본 사항을 다루기 위해해야 ​​할 일이 많습니다. TDD가 도움이 될지 확실하지 않습니다.

다른 답변에 동의하지만 매우 중요한 요점을 추가하고 싶습니다 : 비용 리팩토링 !!

잘 작성된 단위 테스트를 사용하면 코드를 안전하게 다시 작성할 수 있습니다. 첫째, 잘 작성된 단위 테스트는 코드 의도에 대한 훌륭한 문서를 제공합니다. 둘째, 리팩토링의 불행한 부작용은 기존 테스트 스위트에 포함됩니다. 따라서 이전 코드의 가정이 새 코드에도 적용된다는 것을 보증했습니다.

다른 사람들은 모든 생산성과 동기를 없애지 않고 TDD에서 어떻게 살아남습니까?

이것은 내 경험과 완전히 다릅니다. 놀랍도록 지능적이며 버그가없는 코드를 작성하거나 (예 : 하나의 오류로 인해) 코드에 프로그램이 작동하지 못하게하는 버그가 있다는 사실을 알지 못하므로 실제로 완료되지 않았습니다.

TDD는 당신 (그리고 나!)이 실수를한다는 것을 아는 겸손을 갖는 것입니다.

나에게 단위 테스트 작성 시간은 처음부터 TDD를 사용하여 수행 된 프로젝트의 디버깅 시간이 단축되는 것 이상을 절약합니다.

실수하지 않으면 TDD가 나만큼 중요하지 않을 수도 있습니다!

나는 몇 가지 언급 만했습니다.

1. 모든 것을 테스트하려고하는 것 같습니다 . 특정 코드 / 메소드의 위험이 높고 가장자리가 높은 경우는 아닙니다. 80/20 규칙이 여기에 적용된다고 확신합니다. 코드의 마지막 20 % 또는 다루지 않은 경우에 대해 80 %의 테스트 작성 시간을 보냅니다.

2. 우선 순위를 정하십시오. 민첩한 소프트웨어 개발을 시작하고 한 달 안에 릴리스하기 위해 실제로 실제로해야 할 일 목록을 작성하십시오. 그런 다음 그대로 놓습니다. 기능의 우선 순위에 대해 생각하게됩니다. 예, 캐릭터가 백 플립을 할 수 있다면 멋지지만 비즈니스 가치는 있습니까?

TDD는 훌륭하지만 100 % 테스트 범위를 목표로하지 않는 경우에만 실제 비즈니스 가치 (예 : 기능, 게임에 무언가를 추가하는 것)를 생성하지 못하게하는 것이 아닙니다.

예, 테스트 및 코드 작성은 코드 작성보다 시간이 오래 걸리지 만 코드 및 관련 단위 테스트 작성 (TDD 사용)은 코드를 작성하고 디버깅하는 것보다 훨씬 더 예측 가능합니다.

TDD를 사용하면 디버깅이 거의 제거되어 모든 개발 프로세스를 훨씬 더 예측 가능하고 결국 더 빠릅니다.

지속적인 리팩토링-포괄적 인 단위 테스트 스위트 없이는 심각한 리팩토링을 수행 할 수 없습니다. 단위 테스트 기반 안전망을 구축하는 가장 효율적인 방법은 TDD 중입니다. 잘 리팩토링 된 코드는 코드를 유지 관리하는 디자이너 / 팀의 전반적인 생산성을 크게 향상시킵니다.

게임의 범위를 좁히고 누군가가 게임을하거나 공개 할 수있는 곳으로 가져 가십시오. 게임을 출시하기에 너무 오래 기다리지 않고 테스트 표준을 유지하면 동기 부여를위한 중간 단계가 될 수 있습니다. 사용자의 피드백은 장기적으로 이점을 제공 할 수 있으며 테스트를 통해 추가 및 변경에 대해 편안하게 느낄 수 있습니다.