저는 대기업에서 일하지만 데스크톱 LOB 응용 프로그램을 개발하는 단 두 사람의 팀에서 일하고 있습니다. 나는 지금 TDD를 꽤 오랫동안 연구 해 왔으며 더 큰 응용 프로그램의 이점을 쉽게 알 수 있지만 응용 프로그램 규모에서 TDD를 사용하기 시작하는 시간을 정당화하기가 어렵습니다.

테스트 자동화, 유지 관리 성 개선 등의 이점을 이해하지만 규모에 따라 모든 구성 요소에 대한 기본 단위 테스트조차 작성하면 개발 시간이 두 배로 늘어날 수 있습니다. 우리는 이미 마감 시한이 너무 늦었 기 때문에 어떤 방향을 취할지 잘 모르겠습니다. 민첩한 반복 개발과 같은 다른 관행이 완벽 해졌지만 소규모 팀에서 TDD의 생산성 상충 관계를 극복했습니다.

일정이 빡빡한 소규모 팀에서 TDD의 장점은 추가 개발 시간에 가치가 있습니까?

못생긴 진실은 처음에 당신을 느리게 할 것 입니다. 새로운 프로세스 나 실습은 시작하는 데 다소 시간이 걸립니다. 내 경험상 TDD는 유지 보수, 버그 수정 및 확장만큼 초기 구현으로 지불하지 않습니다. 다른 사람들에게는 즉각적인 지불금이 있다는 것을 알고 있으므로 각 사람의 현재 코딩 스타일에 따라 다릅니다.

나는 TDD의 큰 지지자 (현재 직장으로 가져 왔음 ) 를 연습하고 탐구하기 위해 약간의 호흡 공간 (마감일 / 타임 라인) 이 필요하다고 생각합니다 .

팀 규모가 작을수록 TDD로 더 많은 혜택을 얻을 수 있습니다. 6에서 3까지의 팀 규모 로이 지불금을 보았습니다.

당신이 말하는 추가 개발 시간은 환상 일 수 있습니다 .

TDD를 표준 단위 테스트와 다른 점은 테스트를하는 데만 사용되는 것이 아니라는 것입니다.

TDD is a new way of developing software. 내가 아는 가장 좋은 방법 중 하나입니다.

따라서 프로젝트 크기와 관련이 없습니다. 첫 번째 코드 줄에서 이점을 추출합니다 .

• 유지 관리 및 재사용이 더 쉬운 방식으로 코드를 구성해야합니다. 소프트웨어 디자인을 주도합니다.
• 리팩토링이 빠르고 안전하며 즐거워집니다.
• 작업을 훨씬 쉽게 구현할 수 있도록 작은 기능 덩어리를 작성하는 데 도움이됩니다.
• 일반적으로 디버깅 작업이 덜 빈번합니다.

일반적인 오해, 외쳐 보자.

TDD의 테스트는 기능을위한 것입니다

EOM.

편집 : 자세히 설명하겠습니다. "모든 구성 요소 또는 모든 구성 요소에 대한 단위 테스트 작성"은 TDD가 아닌 단위 테스트 입니다. 저는 일인 팀에서 TDD를 정기적으로 사용하여 큰 성공을 거두었습니다. 대가는 특별하다.

TDD, 단위 테스트 기술 ( 공식 사이트 ) 에 대한 훌륭한 책 이 있습니다. 좋은 부분은 "조직에 단위 테스트 통합"-8 장 및 "레거시 코드 작업"-9 장과 같은 문제를 고려한 전체 장이 있다는 것입니다.이 분야의 전문가는 아니지만 (아직 :-)) 내 경험에 따르면 이것이 좋은 출발점이라고 생각합니다.

답을 얻으려면 몇 가지 질문이 있습니다.

1. 코드에서 버그를 수정 한 후 얼마나 많은 시간을 소비합니까? 이것을 정량화 할 수 있다면 "추가"시간과 같거나 초과하는 것을 알 수 있습니다. 이러한 버그가 발생하지 않도록 테스트를 작성해야합니다.

2. 코드를 리팩터링하거나 새로운 기능을 추가하기위한 명백한 편집 작업은 얼마나 자주 관련이없는 것으로 나타 났습니까? 다시 테스트 범위가 좋으면이를 줄일 수 있습니다.

당신이 이것에 정확한 숫자를 넣을 수 없더라도, 당신은 어쨌든이 시간을 보내고 있다는 것을 보여줄 수있을 것입니다. 그래서 당신은 그것을 "선두"로 쓰고 (더욱 희망적으로) 훨씬 더 안정적인 제품으로 끝낼 것입니다.

사람들이 팀에서 테스트를 시작하는 것에 대해 이야기 할 때, 나는 항상 테스트가 어떻게 실행 될지 항상 확인합니다. 종종 팀이 지속적으로 구축되지 않습니다. 리소스가 제한적이라면 CI 서버를 설정하는 것이 테스트를 진지하게 시작하기위한 전제 조건이라고 제안합니다.

설정이 완료되면 TDD 연습을 시작하십시오. 테스트를 염두에두고 시스템을 개발하지 않았다면 기존 코드를 테스트 할 수있게 만드는 데 어려움을 겪을 수 있으며 시스템을 재구성하는 데 비용이 많이 듭니다.

의존성이 거의없는 새로운 클래스 또는 모듈 인 TDD로 쉽게 시작할 수있는 장소를 찾아 시작하십시오. 유틸리티 클래스와 데이터 구조는 종종 좋은 것입니다.

코드에 대한 생각 방식이 어떻게 바뀌는 지, 코드가 얼마나 나은지, 그 코드에 대한 자신감이 어느 정도인지를 느껴보십시오.

나는 그 질문에 실제로 대답하지 않았다는 것을 알고 있지만, 내 요점은 엄청난 추가 비용 없이이 모든 것을 할 수 있어야한다는 것입니다. 첫 번째 예제를 통해 프로젝트의 장점을 더 잘 이해할 수 있습니다.

결론-개발 속도는 느리지 만 결함은 적으므로 버그 수정 시간이 훨씬 줄어 듭니다.

여기에서 Behavior Driven Development가 즉각적인 이익을 얻는다고 생각하지만 테스트 중심 개발이 확실하지 않습니다.

행동 중심 개발에서는 다른 방식으로 티켓에 접근합니다. 비즈니스 담당자와 함께 앉아서이 기능 덩어리가 가져야하는 행동을 정의합니다. 내 블로그의 게시물 ( 작문 제목 : Writing Behaviors ) 에이 내용을 설명합니다 .

비즈니스 사람이나 누군가와 함께 앉으면 모든 사람이 해당 기능에 만족하기 위해 시스템이 무엇을해야하는지 더 잘 이해하도록 도울 수 있습니다. 현재 진행중인 QA 프로세스에서 승인을 받으려면 수행해야 할 작업입니다.

테스트 기준을 정의한 다음 해당 테스트 기준을 자동화 된 테스트 제품군에 작성하면 얻을 수있는 양을 줄여야합니다. 누군가가 무언가를 놓 쳤기 때문에 (합법적으로 놓친 것이거나 전혀 말하지 않았기 때문에 기능이 손상되었다고 주장하는 사람) 그것에 대해 당신).

또한 팀에 대한 다른 사람들의 인식에 도움이 될 수 있습니다. 앉아서 시스템에서 수행해야 할 작업을 정의하면 "모든 것을 과도하게 설계하고 우리가 요청하지 않은 것에 시간을 보내는 바보들", "유용한 기능을 갖춘 똑똑한 사람들".

TL; DR : 행동 중심 개발은 "고객"에 초점을 맞추기 때문에 빠르게 개선 될 수 있습니다. 테스트 주도 개발은 "아무도"신경 쓰지 않는 코드베이스의 내부 테스트에 관한 것으로 보이지만 비즈니스 이점이 덜 분명합니다. (행동 중심 개발은 즉각적인 변화를 가져 왔습니다. 엔지니어는 갑자기 "고객"또는 비즈니스 분석가와 함께이 문제를 바로 잡기 위해 더 많은 시간을 보내고 있습니다. , 그들은 기능 X에 관한 회의를 가졌습니다. 그것은 그 진전이 진전되었음을 의미합니다! ")