테스트 주도 개발-설득하십시오! [닫은]

일부 사람들은 테스트 주도 개발의 대규모 지지자라는 것을 알고 있습니다. 과거에는 단위 테스트를 사용했지만 쉽게 테스트 할 수 있거나 정확하다고 생각되는 작업 만 테스트했습니다. 시간이 많이 걸리는 것처럼 완벽하거나 거의 완전한 코드 범위 소리.

1. 테스트 중심 개발을 위해 어떤 프로젝트를 사용하십니까? 특정 크기 이상의 프로젝트에만 사용합니까?
2. 사용해야합니까? 설득 해!

좋아, TDD의 장점은 다음과 같습니다.

1. 그것은 당신이 더 많은 테스트를 마친다는 것을 의미합니다. 모두가 좋아 가지고 같은 시험, 그러나 몇몇 사람들 작성 을. 개발 흐름에 테스트 작성을 작성하면 더 많은 테스트가 필요합니다.
2. 테스트를 작성하면 디자인의 테스트 가능성에 대해 생각해야하며 테스트 가능한 디자인은 거의 항상 더 나은 디자인입니다. 이것이 왜 그런 일인지는 분명하지 않지만, 저의 경험과 대부분의 TDD 복음 전도자들의 경험은 그것을 드러내는 것 같습니다.
3. 여기에 TDD가 작성하는 데 시간이 조금 더 걸리지 만 더 높은 품질의 코드를 얻을 수 있으므로 수정해야 할 버그가 적어 투자 수익률이 높다는 연구 결과가 있습니다.
4. 리팩토링에 대한 확신을줍니다. 단위 테스트로 잘 다루어지기 때문에 다른 모든 것을 깨뜨리지 않고 하나의 시스템을 변경할 수 있다는 것은 좋은 느낌입니다.
5. 찾은 모든 버그가 수정되기 전에 테스트를 받아야하기 때문에 반복 버그는 거의 발생하지 않습니다.

당신은 확신을 요청했습니다, 그래서 이것들은 혜택이었습니다. 보다 균형 잡힌 견해를 보려면 이 질문 을 참조하십시오 .

Robert C. Martin은 원래 이러한 점을 지적했습니다. 본인의 경험을 바탕으로이를 뒷받침 할 수 있습니다.

• 갈 때마다 단위 테스트의 회귀 테스트 스위트가 자동으로 작성됩니다.
• 마치 홀에 코드를 작성하는 것처럼 디버깅에 거의 시간을 소비하지 않으므로 디버거를 열지 않고 마지막 테스트가 통과 된 시점까지 코드를 실행 취소하는 것이 더 쉽습니다.
• 몇 분마다 코드가 작동하는지 확인합니다. 모든 코드 (또는 테스트에서 다루는 모든 동작, TDD를 수행하는 경우 코드의 비율이 매우 높음).

프로덕션 또는 플레이 코드 작업 중이 든 항상 TDD를 거의 수행합니다. 요즘 다른 방법으로 코딩하기가 어렵습니다.

(면책 조항 : UI를 거의 사용하지 않으므로 UI에 대한 TDD에 대해 논의 할 수 없습니다.)

나는 사소한 응용 프로그램에서 전체 SIP 스택에 이르기까지 거의 모든 작업에서 TDD를 사용합니다.

내가 인수 한 기존 PHP 웹 사이트에서 TDD를 사용하지 않습니다. 나는 시험이없는 것이 고통 스럽다는 것을 알았습니다. 그리고 나는 회귀 테스트 스위트가 없어서 무언가를 깨뜨렸다 고 알려주기 때문에 사이트의 일부를 실수로 깨뜨리는 것이 매우 성가시다. 클라이언트는 (a) 코드베이스에 대한 테스트를 작성하고 (b) 프로세스에서 코드를 처음에 테스트 할 수 있도록 예산이 없습니다.

• 고객에게보다 효과적으로 공급할 수있을 때마다 (테스트와 관련이있을 수 있으며 최소한 프로젝트 종료 토론을 줄입니다)
• 테스트 개발에 노력을 기울이는 것보다 공동 개발자가 코드의 모든 것에 대해 정보를 얻는 데 시간이 더 걸릴 때마다-생각보다 빨리

뭐? 부정적인 대답이 없습니다!?

면책 조항 : 나는 반 단위 테스트가 아닙니다. 사람들이 TDD라고 말할 때, 나는 그들이 작성한 모든 코드의 80-100 %에 대한 코드를 작성하기 전에 테스트를 작성하는 질병 소리 버전을 의미한다고 가정합니다.

나는 주장 할 것이다 :

• 인 에이 블러입니다. 회귀 문제를 포착하는 것이 큰 문제라면 처음부터 완전 자동 TDD가 가치가있는 것처럼 보일 때마다 마지막으로 작성한 코드 조각마다 테스트를 작성하면 실제 문제를 무시하는 데 실제로 도움이 될 수 있습니다.

• 사람들이 실제 문제를 무시하도록 도와줍니다. 하나의 버그를 수정하면 두 개의 팝업이 추가되는 whack-a-mole 게임으로 바뀌어 아키텍처가 불고 있습니다. 초점. 실제 문제에 집중하십시오. 그들이 두들겨지기 전에 두더지를 보는 것은 깔끔하지만 처음에는 거기에 있으면 안됩니다.

• 시간이 많이 걸립니다. 가끔 버그가 발생했습니다. 나는 너무 많이 치지 않기 때문에 내가 쓰는 모든 새로운 것을 접두사로 붙일 가치가있는 것처럼 보입니다. 발생할 수있는 문제를 파악하십시오. 쉽게 진단 할 수 있도록 오류를 처리하십시오. 확인하십시오. 중복 / 병목 지점의 주요 지점에서 테스트합니다. 그러나 큰 소리로 울부 짖기 위해 모든 마지막 게터와 세터를 처음에는 테스트하지 않았어야 할 것으로 테스트하지 마십시오.

• 디자인 포커스 : 우수한 개발자도 테스트에 집중할 때 가능한 최상의 코드를 작성할 방법이 없습니다. 괜찮은 디자인을 할 수있는 유일한 방법 인 것 같으면 위의 "실제 문제에 중점을 두는"방법을 추천합니다.

• Macro-Design Fail : 현재 직장의 코드베이스는 한 번 이상 사용되지 않는 인터페이스와 사람들이 테스트 프레임 워크 및 테스트를 위해 글을 쓰고 있다는 것을 깨달았을 때 마침내 이해하기 시작한 기본 DRY 원칙에 대한 엄청난 위반으로 가득 차 있습니다. 일반. 테스트가 어리석은 아키텍처로 이어지지 않아야합니다. 실제로 20 개의 파일을 복사하여 붙여 넣은 다음 두 파일 만 크게 변경하는 데있어 확장 성 또는 엔터프라이즈 가치가있는 것은 없습니다. 아이디어는 우려를 분리하고 중간으로 나누지 않는 것입니다. Cruft와 무의미한 추상화는 95 %의 적용 범위를 갖지 않는 것보다 더 많은 비용이 듭니다.

• 정말 인기가 있고 많은 사람들이 정말 좋아합니다. 만약 그것이 채택되기 전에 적어도 어떤 기술에 대한 헛소리를 제거하고 /하거나 헛소리를 조사하기에 충분한 이유가 없다면, 편집증을 배우십시오.