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

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

나는 주장 할 것이다 :

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

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

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

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

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

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

답변