테스트 주도 개발은 누구입니까?

나는 지난 4 년 반 동안 엔터프라이즈 영역에서 일해 왔으며, 일반적으로 엔터프라이즈는 테스트 우선 개발 스타일에 적합한 환경이 아니라는 것을 알았습니다. 프로젝트는 일반적으로 고정 비용, 고정 일정 및 폭포 스타일입니다. 모든 단위 테스트는 일반적으로 QA 단계에서 개발 후 다른 팀에서 수행 한 후 수행됩니다.

저는 기업에서 일하기 전에 많은 중소 기업에 대해 컨설팅을했으며 그 중 어느 것도 테스트 우선 스타일의 개발 프로젝트 비용을 지불 할 의사가 없었습니다. 그들은 보통 개발이 즉시 시작되기를 원하거나 짧은 설계가 끝난 후 즉, 애자일과 더 유사한 것을 원했지만 일부 고객은 폭포와 비슷한 모든 것을 원했습니다.

테스트 중심 개발은 어떤 유형의 상점, 회사 및 고객에게 가장 효과적입니까? 어떤 유형의 프로젝트가 TDD에 도움이되는 경향이 있습니까?

내가 작성한 모든 코드 줄은 테스트 중심 개발을 사용하고 있습니다. 경영진이 먼저 필기 시험에 참여하지 않으면 경영진에 대해 말하지 않습니다. 테스트 주도 개발이 더 나은 프로세스라고 강력하게 생각합니다.

내 상사는 오늘 이것에 대해 좋은 것을 먹었습니다. 나는 다른 사람에게서 그것을 훔치는 것처럼 그것을 훔칠 것이라고 생각합니다.

"목수가 보드를 자르기 전에 보드를 측정 할 것으로 기대하십니까?"

고등학교에서 나무 가게 수업을 들었고 학교를 통해 공사를했습니다. 우리의 진언은 항상 "두 번 측정하고 한 번 자르십시오"는 냉소가 뒤따 랐습니다. "나는 그것을 자르고 다시 자르고 여전히 너무 짧았습니다!"

테스트 한 후에 작성하면 코드를 테스트하기가 어렵 기 때문에 재 작업을 만듭니다. 처음 테스트 할 때, 또는 커밋하기 전에 약간의 비트를 테스트 할 때 테스트하는 것이 더 쉬울 것입니다. 체크리스트를 충족시키기 위해 생산 코드가 작성된 후 단위 테스트를 작성하는 기업은 노력을 낭비하고 있습니다.

테스트하기 어려운 기존 소프트웨어와의 통합으로 인해 추가 노력이 필요합니다. 테스트 솔기를 생성하여 반짝이는 새 테스트 구동 코드가 소비하는 종속성을 제어 할 수 있어야합니다. 글로벌 상태와 신 객체를 많이 사용하는 프레임 워크와 같은 경우에는이를 달성하기가 매우 어려울 수 있습니다. 테스트 주도 개발의 인식 된 어려움은 종종 좋은 테스트를 작성하고 밀접하게 결합 된 코드를 테스트하려는 경험과 경험의 조합에 기인합니다.

폭포 형 프로젝트에서도 드라이브 코드를 테스트 할 수 있습니다. 이는 프로젝트 관리 기술이 아닌 엔지니어링 분야입니다.

나는 TDD 광신자가 아니지만 소프트웨어 디자인에 대해 많은 것을 가르쳐줍니다.

이것은 독특하게 .Net 풍미를 가질 것이기 때문에 나와 함께 견디십시오 : p

테스트 우선 접근 방식을 따르는 프로젝트 유형과 관련하여 다음 사항을 살펴보십시오.

• 기존 코드베이스를 다루고 있습니까? 테스트 스위트를 개조하는 것은 종종 엄청나게 비싸다. 상속 된 기술 부채가 얼마나되는지 생각하라
• 특정 플랫폼과 프레임 워크는 본질적으로 테스트에 익숙하지 않습니다. 예를 들어 SharePoint와 같은 최근 경험은 TDD에 매우 어렵지만 불가능하지는 않습니다. 이와 같은 것들을 위해서는 TypeMock과 같은 상용 아이솔레이터 제품을 사용해야 할 수도 있습니다.
• 특정 구현 방식은 다른 방식보다 TDD에 더 적합합니다. 예를 들어 코드 숨김이있는 ASP.Net은 테스트 할 수 없습니다. ASP.Net MVC-테스트 가능 코드 숨김이있는 Silverlight는 테스트 할 수 없습니다. MVVM이 포함 된 Silverlight-테스트 가능

궁극적으로 "조직"은 테스트 우선으로의 전환을 지원하기 위해 많은 노력을 기울일 수 있지만, 개발자가 생각해야 할 주요 변화는 바로 개발자입니다. 나는 "네가 먼저 테스트를 작성해야한다"라는 접근 방식을 포기하고 대신 가르치는 순간을 찾는다.

mgmt에 문제가 있는지 알려주지 않는 것에 대한 mpenrow의 의견에 +1 : p

당신의 상황은 빠르게 변하지 않을 것이며, 그것을 극복하는 열쇠는 그것을 다른 사람에게 강요하기 전에 그것을 당신의 개인적인 징계의 일부로 만들고 그것을 능숙하게하는 것입니다. 당신이 그것이 작동하는 예가 될 수 있다면 관리자는 객관적인 이점을 볼 수 있습니다.

좋은 비즈니스 사례를 만들 수도 있습니다.

• TDD는 간단히 "시스템이 자동으로 검증 할 수있는 사양"으로 요약 할 수 있습니다. 다르게 프로그래밍하지 않고 다른 제품을 만들지 않습니다.

• 단위 테스트는 실제로 자동 테스트의 한 형태 일뿐입니다. 이것은 회사가 육체 우주 엔지니어에게 수동으로하는 일을 지불 할 가능성이있는 것을 컴퓨터가 스스로 할 수있게 해줍니다. 자동화 된 테스트는보다 빠르고 일관성있게 작성되며, 잘 작성된 경우에는 빠르고 간결하고 정확한 피드백과 설명 및 문제의 방향을 제공합니다.

• TDD는 자신이하는 일을 알고있는 사람에 의해 수행 될 때 코드 우선만큼 빨리 결과를 생성합니다. 학습 / 훈련 곡선이있을 것입니다 (그리고 엔지니어가 인재 풀의 최후 단계 인 경우 TDD를 추진할 가능성이 완전히 없어 질 수 있습니다.이 경우에는 계속해서 우승하는 것이 좋습니다 그리고 TDD가 아닌 경영진에게 질문 합니다 )

• TDD는 시작하기 전에 당면한 작업을 통해 생각하는 것에 관한 것입니다. "두 번 측정하고 한 번 자르십시오"라는 선을 따라야합니다. 여분의 측정은 작업에 약간의 시간을 추가하지만 가장 소중한 자원 인 dev 시간을 버리지 않습니다.

... 그리고 기억하세요; 당신이 할 수있는 가장 중요한 일은 모범을 보이는 것입니다. TDD에 익숙하지 않다면 더 나은 시간을 내기 위해 몇 시간을 더 투자하십시오. 능숙 해지면 직장에서 작업을 시작하십시오 (매니저가 실제로 시험을 치른다 고 불평할까요?). 한 번에 한 번의 전투에서 싸우고 그쪽으로 나아가십시오. 세방 전체를 다가 가면 실패로 이어질 것이며, 당신이 그것을 강하게 밀면 그 책임이 당신에게 떨어질 것입니다.

나는한다. 선호하는 개발 방식이며 마감일을 지키고 품질 코드를 작성하는 한 본인에게 맞는 방식으로 일하기를 좋아하는 대기업 금융 회사에서 일합니다. 올바르게 수행하고 테스트 첫 번째 개발은 개발 후 테스트보다 오래 걸리지 않으며 나중에 시스템 테스트에서 결함이 적은 다른 첫 번째 테스트 개발에 대한 보상을 잊지 마십시오.

TDD를 수행의 핵심은 당신의 코드를 작성의 일환으로 그것을 할, 그리고 필요한 경우, 당신은 당신이 그것을하고있는 사람을 말하지 않습니다. 하고있는 모든 것을 설명 할 필요는 없습니다. 최종 결과는 작동 코드입니다.

"테스트를 작성 중입니다"라고 설명하면 The Powers Be Be는 "아, 제거 할 수 있습니다!"라고 말할 수 있습니다. 그러나 아무에게도 말하지 않으면 코딩 과정의 잔여 물로 테스트를 계속합니다.

프로그래밍은 작업 설명을 편집기에 입력하는 것 이상입니다. 사람들이 그것을 다룰 수 없다면, 그들이 다룰 준비가 될 때까지이 진리로부터 그들을 보호하십시오. 이 경우 "처리 할 준비가되었습니다"는 견실하고 신뢰할 수있는 코드로 정시에 완료된 프로젝트를 한두 번 완료했을 때를 의미합니다.

슬프게도, 나는 그것을 정말로 고전적인 테스트 우선 감각으로 사용할 기회를 얻지 못했기 때문에 "나! 나! 나 해!"라고 말할 수는 없습니다. 나는 "누군가가 일상 생활에 TDD를 몰래 넣을 수 있는가"가 아니라 "업계 전반에 걸쳐 어떤 산업 / 회사가 TDD를 사용 하는가"라고 묻고 있다고 가정합니다. 나는 개별 개발자가 전체 그룹이 강제로 TDD를 수행하지 않고도 TDD를 완전히 수행 할 수 있다는 데 동의합니다.

업계를 청취하면서 얻은 인상은 다음과 같은 상황에서 회사의 대부분의 개발 그룹에서 TDD를 볼 가능성이 높다는 것입니다.

• TDD가 시작되기 전에 기존 코드베이스가 크지 않습니다

• 이 회사는 그다지 크지 않기 때문에 "우리는 항상 다른 방식으로 해왔었다"푸시 백을 많이하지 않습니다.

• 이 회사는 공식화 된 프로세스에 대해 막대한 구매를하지 않았습니다. CMMI 인증 회사와 같이 TDD를 구현할 수 없다는 것은 아닙니다. 그러나 TDD 프로세스가 아닌 경우 CMMI로 모니터링하는 모든 프로세스를 업데이트하는 것이 큰 투자가 될 수 있습니다.

• 테스트를 스크립팅 할 수 있습니다. 가장 복잡한 코드 기반입니다. 사용자에게 가장 가까운 레이어를 쉽게 스크립팅 할 수 없어도 내부를 스크립팅 할 수 있기 때문입니다. 그러나 테스트 자동화를 위해 잘 개발 된 옵션이있는 상황은 TDD의 가장 좋은 지점이라고 생각합니다. 테스트에 대한 피드백이 매우 빨리 필요한 전체 테스트 배터리를 다시 실행하고 중단하지 않기 때문입니다. 내 생각에 독립형 웹 앱은 좋은 TDD 대상이며, 주요 COTS 통합 또는 GUI 기반이 아닌 입력을 가진 시스템은 까다로울 수 있습니다.

• 프로토 타입이 아닌 상태의 시스템. 이상적으로 다음 큰 버전 이후 프로토 타입 - 개념의 증명이 완료하고 프로젝트가 자금을 지원하지만, 모두가 다음 시도가 품질에 점프하는 것을 알고 곳.

• 프로세스에 투자 한 이해 관계자

가능한 곳에서 시도했지만 실제로는 자신이있는 회사 환경에 달려 있다고 생각합니다. 나는 게임 업계에서 수년간 (예술가 btw로서) 일했으며 TDD에 대한 개념은 없었습니다. 나는 웹 개발로 옮겼지만 아직 공식적인 인정 (또는 지식) 단위 테스트 / TDD를 가진 기관에서 일하지 않았다. 광범위한 분야에서 일하는 업계 동료들도 마찬가지입니다.

판매 중심 대행사에서 TDD는 고객에게 단기 ROI를 거의 제공하지 않으므로 프로젝트 범위를 지정할 때 라인 관리자에게 판매하기가 어렵습니다. 그러나 프로젝트가 커질수록 더 확실해집니다.

데스 3 월 (Death March) 과 같은 책 이 널리 알려진 현상, 즉 "크런치"와 "마일스톤"주도 개발에 시달리고있는 산업을 지적한다는 점을 감안할 때 , TDD는 자금이 부족한 신생 기업이나 모 놀리 식 기업 상점 외부에서는 드물다. TDD의 가치를 믿지 않는 사람들이 아니라 고객에게 판매하기에는 너무 추상적입니다.

TDD에 들어 가려고합니다. 나는 당신이 이미 알고있는 경로를 따르는 한 (매일 일하는) 다소 간단하다고 생각합니다. 그러나 UI 부분에 대한 테스트를 둘러 보거나 이전에 경험하지 못한 일부 문제에 대한 새로운 솔루션을 제시해야 할 때 머리를 감쌀 수는 없습니다. 또는 모르는 프레임 워크를 사용하십시오.

그래서 당신은 일종의 LearningTests를 수행하고, 개념 증명을 분리하고 나중에 다시 쓰는 등을해야한다고 생각합니까?

그리고 (이것은 오래된 것이지만 아직 좋은 대답을 보지 못했습니다) : 어떻게 TDD를 사용하여 알고리즘을 코딩합니까?

보트에서 TDD와 im의 긍정적 인면을 실제로 볼 수는 있지만 작성하는 코드가 시간을 거의 두 배로 늘릴 때 초보자에게는 매우 어렵습니다. RAD와 함께)

나는 몇 번 시도했지만 훌륭하게 작동했습니다. 불행히도 대부분의 경우 내 앱을 수동으로 테스트 할 수 있다면 다른 것을 구현하기에 너무 지루하다고 느끼거나 쉽게 해결할 수없는 버그가있을 때까지 단위 테스트를 연기합니다.

내가한다. 사용자 스토리의 진행 상황은 "테스트가 있습니까?" 라는 Kanban 보드에서 추적됩니다. 개발의 왼쪽 (업스트림) 열.

이 다소 특이한 레이아웃은 하나의 정책을 명시 적으로 만듭니다. 실패한 자동 수락 테스트 (일반적으로 몇 가지)가 존재해야합니다. 고객 요구 사항을 추적 할 수 있어야합니다. 수용 테스트 는 스토리 카드로 시작하는 대화의 결과 인 만족 조건 에서 발생 합니다 . 나는 우리가 요구 사항을 브레인 스토밍하고 격차를 식별하며 사용자 가치가 전달 될 때 사용자 가치가 전달되도록하는 주요 수용 테스트를 수행하는 정기 워크샵을 진행합니다 ( 정의 정의 ). 프로그래머, 비즈니스 분석가 및 때로는 테스터가 참여하는 협업 활동입니다.

수용 테스트 피드백 루프는 시간이 오래 걸립니다. 스토리를 완료하는 데 며칠이 걸릴 수 있습니다. 개발에는 더 짧은 자체 TDD 피드백 루프가 있습니다.

"[... 테스트 우선 스타일이 없습니다 ...] 애자일과 더 유사합니다 ...."

이것은 애자일의 완전한 허위 진술입니다. 완료의 정의는 애자일의 핵심 구성 요소이며 그 기초가되는 기둥 중 하나는 자동화 된 승인 테스트입니다 (위에서 설명한 방법 중 하나입니다). 익스트림 프로그래밍 (XP)이 애자일 구현 방법으로 사용되는 경우 ATDD / BDD 및 TDD가 규정되어 있습니다.

나는 일반적으로 UI가 아닌 구성 요소에 대해서만하며, 한 번에 머리에 모듈에 대한 전체 알고리즘을 유지할 수 없거나 모듈이 내가 작업중 인 시스템의 새로운 부분 일 때 따라서 디버깅이 활발히 진행되는 데 사용하는 대부분의 라이브러리에 의존 할 수 없습니다.

본질적으로 요구 사항의 복잡성이 코드에서 길을 잃을 수 있음을 의미 할 때 수행합니다.

시작하는 것은 어려운 습관이며 경영진이 필요하지만 테스트가 개발의 절반을 넘어 서면 생명을 구할 수 있습니다!

실제로 TDD를 수행하고있는 회사 수를 확인하기 위해이 질문을하고 싶었습니다.

11 년 동안 나는 전문적으로 프로그래밍을 해왔으며, 마지막 두 조직 만이 TDD에 대해 알고있었습니다 (이는 TDD가 오늘날만큼 인기가 없었던 5 년 전). TDD의 판매 피치에 들어가기 전에 추격을 줄이고 질문에 대답하겠습니다. :)

내가 일한 마지막 회사 (인문 및 과학 컬렉션의 온라인 학술 출판사)에서 우리는 TDD를 연습해야한다는 것을 알았지 만 결코 거기에 도달하지 못했습니다. 우리의 방어에는 250k 코드 기반이 있었기 때문에 테스트 할 수없는 크기의 코드 기반에 테스트를 추가하는 것은 극복 할 수 없다고 느꼈습니다. 우리 중 최고조차도 실수를 저지 릅니다 .

소량의 TDD조차도 누구나 브라운 필드 필드 테스트 할 수없는 코드에 대한 고통스러운 개조 테스트가 얼마나 될 수 있는지 알고 있습니다 ... 주요 원인은 암시 적 종속성입니다 (코드에서 결과를 주장하기 위해 모든 레버를 뽑을 수는 없습니다-당신은 조롱 할 수 없습니다) 시나리오) 및 단일 책임 원칙 위반 (테스트는 복잡하고, 고려되고, 너무 많은 설정이 필요 하며 이해하기 어렵다 )

출시 전에 플랫폼 을 테스트 하기 위해 QA 팀 (1 명에서 2 명에서 15 명 이상으로)을 일시적으로 성장 시켰습니다 . 시간과 비용이 엄청나게 비쌌으며 일부 테스트는 '테스트'를 완료하는 데 3 개월이 걸렸습니다. 그럼에도 불구하고 우리는 우리가 문제와 함께 선적하고 있다는 것을 알고 있었고, 단지 '차단 자'또는 '중요하지 않은'것이 아니라 '높은 우선 순위'에 불과했습니다.

몇 년 동안 상업적 경험을 쌓았다면 모든 회사가 중요한 작업을 수행 한 다음 그보다 높은 우선 순위를, 특히 그 이상의 사람 이 기능 / 버그 수정을 추진할 때 그보다 높은 우선 순위를 발명 한다는 점에 감사하게 생각합니다 . 나는 산다 ...

Jenkins CI와 함께 현재 회사 (통신, 웹 및 모바일 앱 개발 하우스)에서 TDD를 연습하고 있으며 다른 정적 분석 보고서를 제공합니다 (코드 범위는 테스트 스위트 통과를 주장한 후 가장 유용합니다). . 내가 TDD를 사용한 프로젝트는 지불 시스템과 그리드 컴퓨팅 시스템입니다.

판매 피치 ...

기술이 아닌 팀원에게 자동화 된 테스트를 정당화하는 것은 종종 어려운 일입니다. 테스트를 작성하면 개발 프로세스에 더 많은 작업이 추가되지만 ... 지금 테스트에 투자 할 때 나중에 유지 관리 노력을 절약 할 수 있습니다. 당신은 정말로 시간을 빌리고 있습니다 . 제품을 오래 사용할수록 비용을 크게 절약 할 수 있으며 큰 재 작성 을 피할 수 있습니다 .

먼저 테스트는 인 텐트를 먼저 코딩 한 다음 코드가 해당 의도를 충족하는지 확인하는 것을 의미합니다. 이것은 초점을 제공하고 의도 된 것 이상을 수행하기 위해 코드를 증류합니다 (팽창 없음). 동시에 실행 가능한 사양 및 문서입니다 (테스트가 잘 작성되어 있고 테스트가 시스템 코드만큼 읽기 쉽고 깨끗 해야하는 경우).

프로그래머가 아닌 사람들은 종종 이러한 통찰력을 가지지 못하므로 TDD는 그 가치를 많이 가지지 않으며 이전 릴리스 날짜의 일회용 지름길로 간주됩니다.

프로그래밍은 우리의 영역이며, 제 생각에 이것은 전문가로서 TDD와 같은 모범 사례에 대해 조언 하는 것이 우리의 책임 입니다. 하지가 개발 시간을 단축하기 위해 이루어집니다 경우 프로젝트 관리자가 결정하기 위해, 그것은 그들의 관할권 밖으로이다 . 같은 방식으로 어떤 프레임 워크, 캐싱 솔루션 또는 검색 알고리즘을 사용하는지 알려주지 않고 자동 테스트를 사용해야하는지 여부를 알려주지 않아야합니다.

에서 내 의견으로는 소프트웨어 개발 산업 (전체적으로), 현재 소프트웨어에 대한 테스트를 갖는 표준이 아니라는 사실을 나뉩니다.

의료, 항공, 자동차, 화장품, 부드러운 장난감, 주류 등의 다른 산업에서 이것을 묘사하십시오. 나는 약혼자에게 제품을 테스트하지 않은 업계의 이름을 말하라고했지만 그녀는 할 수 없었습니다!

아마도 테스트가 수행되지 않기 때문에 테스트가 발생하지 않는다고 말하는 것은 불공평합니다. 그러나 자동화 된 테스트가없는 회사에서는 매우 수동적 / 인간적인 (읽기 어려우며 종종 오류가 발생하기 쉬운) 프로세스입니다.

한 가지 점은 귀하의 질문에 대해 논쟁 할 것입니다 ...

그들은 일반적으로 개발이 즉시 시작되기를 원하거나 짧은 설계가 끝난 후에 원했습니다. 애자일과 더 유사합니다.

이어서 "애자"는 시험없이 진행 규정하지 않습니다에 나열된 첫 번째 멤버 agilemanifesto.org는 이다 켄트 벡 (Kent Beck) , XP와 TDD의 창조자!

TDD에 관심이 있거나 책을 읽지 않았고 예리한 프로그래머라면 두 권의 책을 적극 추천합니다.

테스트에 따라 성장하는 객체 지향 소프트웨어

Clean Code-Robert C Martin ( "Uncle Bob") 시리즈

이 두 권의 책은 서로를 칭찬하고 몇 페이지로 많은 의미를 응축합니다.

이 질문을 해 주셔서 감사합니다 :)

클론을 구현하는 사람들. 기존 프로그램과 똑같이 작동하는 무언가를 개발할 때 더 나은 프로세스를 생각할 수 없습니다.

분명히 이것은 매우 드문 경우이지만 SQLite 개발자는 광범위하게 테스트를 사용합니다. (확실하지는 않지만 개발 프로세스가 테스트 우선이라고 가정합니다.)

• 73,000 줄의 코드
• 91,378,600 줄의 테스트 코드

http://www.sqlite.org/testing.html을 참조 하십시오