왜 TDD가 작동합니까? [닫은]

요즘 테스트 중심 개발 (TDD) 이 큽니다. 프로그래머 SE 및 기타 장소에서 광범위한 문제에 대한 솔루션으로 권장되는 경우가 많습니다. 왜 작동하는지 궁금합니다.

엔지니어링 관점에서 볼 때 두 가지 이유로 당황합니다.

1. "쓰기 테스트 + 통과까지 리팩터링"접근 방식은 매우 반 엔지니어링합니다. 예를 들어 토목 기술자가 교량 건설 또는 자동차 설계를 위해이 접근 방식을 사용한 경우, 교량 또는 차량을 매우 높은 비용으로 개조 할 수 있으며, 결과적으로 잘 고려되지 않은 구조로 인해 엉망진창이 될 수 있습니다. . "통과 리팩토링 리플렉션"가이드 라인은 종종 건축 설계를 잊고 테스트 준수에 필요한 모든 조치를 취해야하는 의무로 간주됩니다 . 즉, 사용자보다는 테스트가 요구 사항을 설정합니다. 이 상황에서 우리는 어떻게 결과에서 좋은 "유일성"을 보장 할 수 있습니까? 즉, 정확할뿐만 아니라 확장 가능하고 강력하며 사용하기 쉽고 신뢰할 수 있고 안전하며 안전한 최종 결과입니까? 이것이 일반적으로 아키텍처가하는 일입니다.
2. 테스트로 시스템이 작동한다고 보장 할 수는 없습니다. 그렇지 않다는 것만 보여줄 수 있습니다. 다시 말해, 테스트에 따르면 테스트에 실패한 시스템에 결함이있는 것으로 나타 났지만 모든 테스트를 통과 한 시스템은 실패한 시스템보다 안전하지 않습니다. 여기서는 테스트 범위, 테스트 품질 및 기타 요소가 중요합니다. "모든 녹색"결과가 많은 사람들에게 발생하는 잘못된 안전 감정은 민간 및 항공 우주 산업에서 매우 위험하다고보고되었습니다. 실제로 "시스템이 훌륭하다"는 것을 의미 할 때 "시스템이 양호하다"라고 해석 될 수 있기 때문입니다. 테스트 전략으로 " 종종 테스트 전략이 점검되지 않습니다. 아니면 누가 테스트를 테스트합니까?

요약하자면, 나는 "테스트"비트보다 TDD의 "구동"비트에 대해 더 우려하고있다. 테스트는 완벽합니다. 내가 얻지 못하는 것은 디자인을 수행하여 디자인을 이끌어내는 것입니다.

소프트웨어 엔지니어링의 TDD가 좋은 방법 인 이유와 위에서 설명한 문제가 소프트웨어의 경우 관련이없는 이유에 대한 답변을보고 싶습니다. 감사합니다.

나는 여기에 하나의 오해가 있다고 생각합니다. 소프트웨어 디자인에서 디자인은 제품에 매우 가깝습니다. 토목 공학, 건축에서 설계는 실제 제품과 분리되어 있습니다. 설계를 유지 한 청사진이 완성 된 제품으로 구체화되고 막대한 시간과 노력으로 분리됩니다.

TDD가 설계를 테스트하고 있습니다. 그러나 모든 자동차 설계 및 건물 설계도 테스트됩니다. 건축 기법을 먼저 계산 한 다음 더 작은 규모로 테스트 한 다음 더 큰 규모로 테스트하여 실제 건물에 배치합니다. 예를 들어 H- 빔과 부하를 발명했을 때 실제로 시도한 후 다시 시도하여 안심할 수 있습니다.

자동차의 디자인은 또한 프로토 타입을 설계함으로써 테스트를 거쳤으며, 그렇습니다. 기대에 부응 할 때까지 정확하지 않은 것을 조정함으로써 확실히 테스트됩니다. 당신이 말했듯이, 당신은 제품을 많이 엉망으로 만들 수 없기 때문에이 과정의 일부는 더 느립니다. 그러나 자동차의 모든 재 설계는 이전의 경험에서 얻은 경험을 바탕으로하며, 모든 건물은 공간, 조명, 단열, 강도 등의 중요성에 대해 약 10 년 동안 근본을두고 있습니다. 새로운 것들을위한 재 설계에서.

또한 부품을 테스트합니다. 아마도 소프트웨어와 정확히 같은 스타일은 아니지만 기계 부품 (바퀴, 점화기, 케이블)은 일반적으로 측정되고 크기가 정확한지, 이상이 없는지 등을 알기 위해 스트레스를받습니다. 측정, 그들은 깨진 벽돌을 발견하기 위해 벽돌을 두드 리거나, 실제로 어떤 구성 또는 다른 테스트에서 테스트 될 수 있거나, 실제로 큰 그룹을 제한적으로 표현하여 테스트에 넣습니다.

이것들은 TDD와 함께 사용할 수있는 모든 것입니다.

실제로 테스트는 보장되지 않습니다. 바람이 불 때 프로그램이 충돌하고 자동차가 고장 나고 건물이 재미있는 일을 시작합니다. 그러나 ... '안전성'은 부울 한 질문이 아닙니다. 모든 것을 포함 할 수없는 경우에도 사건의 99 %가 50 %에 달하는 것보다 더 좋습니다. 강철을 테스트하지 않은 채 발견하지 못하고 제대로 발견되지 않았으며 주 구조를 방금 들었을 때 망치의 첫 타격에서 부서지기 쉽고 깨졌습니다. 여전히 건물을 다치게 할 수있는 다른 우려가 있다고하더라도 쉽게 예방할 수있는 결함으로 인해 설계가 무너지는 것은 어리석지 않습니다.

TDD의 실행에 관해서는, 그것은 균형의 문제입니다. 다른 방법으로 수행하는 비용과 비교하여 한 가지 방법으로 수행하는 비용 (예 : 테스트하지 않고 나중에 조각을 집어 올림). 항상 균형입니다. 그러나 다른 설계 프로세스에는 테스트 및 TDD가 없다고 생각하지 마십시오.

IDD, TDD의 성공 사례는 대부분 가짜이며 마케팅 목적으로 만 사용됩니다. 성공은 거의 없지만 소규모 응용 프로그램에서만 가능합니다. TDD 원칙이 사용되는 큰 은빛 응용 프로그램을 만들고 있습니다. 응용 프로그램이 수백 개의 테스트를 받았지만 여전히 안정적이지 않습니다. 복잡한 사용자 상호 작용으로 인해 응용 프로그램의 여러 부분을 테스트 할 수 없습니다. 모의가 많고 코드를 이해하기 어려운 결과 테스트.

처음에 TDD를 시도했을 때 모두 좋았습니다. 나는 많은 테스트를 작성하고 단위 테스트를하기 힘든 부분을 조롱 할 수있었습니다. 상당한 양의 코드가 있고 인터페이스 변경이 필요하면 문제가 해결 된 것입니다. 많은 테스트를 수정해야하며 실제 코드 변경보다 더 많은 테스트를 다시 작성하게됩니다.

Peter Norvig는 Coders At Work 책에서 TDD에 대한 그의 견해를 설명합니다.

Seibel : 테스트를 사용하여 설계를 추진한다는 아이디어는 어떻습니까?

Norvig : 테스트를 디자인 방식이 아니라 오류를 수정하는 방식으로 본다. "음, 당신이하는 첫 번째 일은 마지막에 정답을 얻는다는 테스트를 작성하는 것"이라고 말한 다음, 당신은 그것을 실행하고 실패한 것을보고, "당신은 무엇을해야합니까? 다음에 필요합니까?”— 나에게 무언가를 디자인하는 올바른 방법이 아닌 것 같습니다. 솔루션이 너무 단순해서 미리 이해가 된 경우에만 보입니다. 먼저 생각해야한다고 생각합니다. “조각은 무엇입니까? 조각이 무엇인지 알 때까지 조각에 대한 테스트를 작성하려면 어떻게해야합니까?”그런 다음 일단 완료하면 각 조각에 대한 테스트를 수행하고 서로 상호 작용하는 방식을 잘 이해하는 것이 좋습니다. 경계 사례 등. 그것들은 모두 테스트를 받아야합니다. 그러나“이 테스트는 실패했습니다.”라고 말함으로써 전체 설계를 추진한다고 생각하지 않습니다.

테스트 구동 설계는 다음과 같은 이유로 저에게 효과적입니다.

사양의 실행 가능한 형식입니다.

이것은 테스트 사례에서 볼 수 있음을 의미합니다.

1. 있는지 예상되는 결과는 테스트 케이스에 바로 있기 때문에 코드가 호출되는 사양을 풀 채 웁니다. 육안 검사 (테스트 사례가 통과 될 것으로 예상)는 즉시 "오,이 테스트에서는이 상황에서 인보이스 회사에 전화를 걸면 그 결과가 있어야합니다"라고 말할 수 있습니다.
2. 코드를 호출하는 방법 테스트를 수행하는 데 필요한 실제 단계는 외부 스캐 폴딩없이 직접 지정됩니다 (데이터베이스는 조롱 등).

먼저 외부에서보기를 작성하십시오.

종종 코드는 문제 를 먼저 해결 하는 방식으로 작성되며 방금 작성한 코드가 어떻게 호출되는지 생각합니다. "플래그를 추가하기"등이 더 쉬우므로 종종 어색한 인터페이스를 제공합니다. 이것은 코드가 다른 방식이 아닌 호출 인터페이스에 따라 작성되므로 더 나은 모듈성을 제공합니다.

이로 인해 일반적으로 코드가 깨끗해져 설명서가 덜 필요합니다.

더 빨리 끝납니다

실행 가능한 양식에 대한 스펙이 있으므로 전체 테스트 스위트가 통과하면 완료됩니다. 더 자세한 수준으로 내용을 명확하게하면 더 많은 테스트를 추가 할 수 있지만 기본 원칙으로 진행 상황과 완료 시점을 매우 명확하고 가시적으로 알 수 있습니다.

즉, 작업이 필요한지 아닌지 (테스트를 통과하는 데 도움이 됨) 알 필요가없는 것을 알 수 있습니다.

그것에 대해 숙고하는 사람들에게 도움이 될 수 있으므로 다음 라이브러리 루틴에 TDD를 사용하는 것이 좋습니다. 실행 가능한 사양을 천천히 설정하고 코드가 테스트를 통과하도록합니다. 완료되면 실행 가능한 스펙을 라이브러리 호출 방법을 알아야하는 모든 사람이 사용할 수 있습니다.

최근 연구

"사례 연구 결과에 따르면 TDD 사례를 사용하지 않은 유사한 프로젝트에 비해 4 가지 제품의 시험판 결함 밀도가 40 %에서 90 % 사이로 감소한 것으로 나타났습니다. "TDD 채택 후 초기 개발 시간" ~ 4 개 산업 팀의 결과 및 경험

소프트웨어 작성 프로세스는 코드 작성 프로세스가 아닙니다. 먼저 '광범위한'계획없이 소프트웨어 프로젝트를 시작해서는 안됩니다. 강의 두 해안을 연결하는 프로젝트와 마찬가지로 먼저 그러한 계획이 필요합니다.

TDD 방식은 (대부분) 단위 테스트와 관련이 있습니다. 최소한 사람들이 그것에 대해 어떻게 생각하는지는 저수준의 소프트웨어 코드 비트를 만드는 것입니다. 모든 기능과 동작이 이미 정의되어 있고 실제로 달성하고자하는 것을 알고있을 때.

구조 공학에서는 다음과 같이 보입니다.

우리는이 두 조각의 금속이 서로 연결되어 있으며,이 연결은 x의 순서로 전단력을 유지해야합니다. 이 작업을 수행하는 데 가장 적합한 연결 방법을 테스트 해 보겠습니다 '

소프트웨어가 전체적으로 작동하는지 테스트하기 위해 사용성 테스트, 통합 테스트 및 승인 테스트와 같은 다른 종류의 테스트를 설계합니다. 이것들은 코드 작성에 대한 실제 작업이 시작되기 전에 정의되어야하며 단위 테스트가 녹색 인 후에 수행됩니다.

V- 모델 참조 : http://en.wikipedia.org/wiki/V-Model_%28software_development%29

다리에서 어떻게 작동하는지 봅시다 :

1. 지방 정부는 교량 건설 회사에 다음과 같이 말합니다. "이 두 지점을 연결하려면 교량이 필요합니다. 교량은 시간당 n 량의 트래픽을 허용하고 2012 년 12 월 21 일에 대비할 수 있어야합니다." 수락 테스트 : 회사는 해당 테스트를 통과 할 수없는 경우 전체 금액의 돈을받지 못합니다.

2. 회사의 관리는 프로젝트 일정을 결정합니다. 이들은 실무팀을 구성하고 각 팀의 목표를 설정합니다. 팀이 이러한 목표를 달성하지 못하면 교량은 제 시간에 세워지지 않습니다. 그러나 여기에는 약간의 유연성이 있습니다. 팀 중 하나에 문제가있는 경우 회사는 전체 프로젝트가 여전히 1 위 목표를 달성 할 수 있도록 요구 사항 변경, 하청 업체 변경, 더 많은 인력 고용 등을 통해 상쇄 할 수 있습니다.

3. 특정 브리지 구성 요소를 설계하는 팀 내에서 위의 예와 같이 보입니다. 우리는 교량 건설에 관한 많은 지식을 가지고 있기 때문에 때로는 해결책이 분명합니다 (소프트웨어 개발에 잘 테스트 된 라이브러리를 사용하는 것과 같습니다-광고 된대로 작동한다고 가정). 때로는 여러 디자인을 만들고 테스트하여 가장 좋은 디자인을 선택해야합니다. 여전히, 구성 요소를 테스트하는 기준은 미리 알려져 있습니다.

내 마음에 TDD가 작동하기 때문에

• 일반적으로 사양이나 요구 사항에 포함되지 않은 수준의 정밀도로 구현을 결정하기 전에 장치에서 수행 할 작업을 정의해야합니다.
• 테스트 및 프로덕션 시나리오 모두에서 코드를 사용해야하므로 코드를 본질적으로 재사용 할 수 있습니다.
• 더 나은 디자인으로 이어지는 덩어리를 테스트하기 위해 작은 eaiser로 코드를 작성하는 것이 좋습니다.

특히 당신이 올리는 포인트에

• 코드는 벽돌이나 강철보다 가단성이 높으므로 수정하는 것이 더 저렴합니다. 동작이 변경되지 않았는지 테스트하는 것이 여전히 저렴합니다.
• TDD는 디자인을하지 말아야 할 변명이 아닙니다. 너무 많은 세부 사항이 아닌 높은 수준의 아키텍처가 여전히 권장됩니다. Big Up Front Design은 권장하지 않지만 충분한 디자인 만 수행하는 것이 좋습니다.
• TDD는 시스템 작동을 보장 할 수는 없지만, 누락 될 수있는 많은 작은 실수가 방지됩니다. 또한 일반적으로 더 나은 팩토링 코드를 권장하기 때문에 이해하기가 더 쉽기 때문에 버그가 적습니다.

TL; DR

프로그래밍은 여전히 ​​디자인 활동이며 건설이 아닙니다. 사실 후에 단위 테스트를 작성하면 코드가 유용한 기능을 수행하는 것이 아니라 코드가 수행하는 기능 만 수행한다는 것만 확인합니다. 테스트 실패는 실수를 조기에 발견 할 수있게하므로 실제 가치입니다.

코드는 디자인이다

PPP 7 장 "Uncle Bob"에서이 문제에 대해 직접 설명합니다. 이 장의 초반에 그는 Jack Reeves 의 훌륭한 기사 를 참조하여 코드가 디자인이라고 제안합니다 (링크는 주제에 대한 세 기사를 모두 수집하는 페이지로 연결됨).

이 주장에서 흥미로운 점은 구성이 매우 비싼 활동 인 다른 엔지니어링 분야와 달리 소프트웨어 구성이 비교적 자유 롭다는 것입니다 (IDE에서 컴파일하면 소프트웨어가 내장되어 있음). 코드 작성을 구성 작업 대신 디자인 작업으로 볼 경우 기본적으로 빨강-녹색 리 팩터주기가 설계의 연습입니다. 테스트를 작성하고 테스트를 만족시키는 코드를 작성하고 새로운 코드를 기존 시스템에 통합하기 위해 리팩토링하면 디자인이 발전합니다.

사양으로 TDD

TDD에 대해 작성하는 단위 테스트는 사양을 이해하는대로 직접 번역 한 것입니다. 사양을 최소한으로 만족시키는 코드를 작성하면 (테스트가 녹색으로 변함) 작성한 모든 코드가 특정 목적을 위해 존재합니다. 해당 목적이 충족되었는지 여부는 반복 가능한 테스트로 검증됩니다.

기능성에 대한 테스트 작성

단위 테스트에서 일반적인 실수는 코드 후에 테스트를 작성할 때 발생하며 코드가 수행하는 작업을 테스트하게됩니다. 다시 말하면 다음과 같은 테스트가 표시됩니다

public class PersonTest:Test
{
   [Test]
   TestNameProperty()
   {
      var person=new Person();
      person.Name="John Doe";
      Assert.AreEqual("John Doe", person.Name);
   }
}

이 코드가 유용 할 수 있다고 생각하지만 (단순한 속성으로 외설적 인 일을하지 않았는지 확인하십시오). 사양의 유효성을 검사하는 것은 아닙니다. 그리고 당신이 말했듯이, 이런 종류의 테스트를 작성하는 것은 지금까지 당신을 필요로합니다.

Green이 좋은 반면 Value는 빨간색으로 나타납니다. 예상치 못한 테스트 실패로 TDD에서 첫 번째 "aha"순간을 보냈습니다. 내가 구축하고있는 프레임 워크에 대해 일련의 테스트를 수행했습니다. 새로운 기능을 추가하여 테스트를 작성했습니다. 그런 다음 테스트를 통과하는 코드를 작성했습니다. 컴파일, 테스트 ... 새로운 테스트에서 초록색을 얻었습니다. 그러나 나는 또 다른 테스트에서 빨간색을 얻었습니다.

실패를 보면서, 나는 그 시험을 제자리에 두지 않았다면 꽤 오랫동안 그 벌레를 잡았을 것이기 때문에 안도의 한숨을 쉬었다. 그리고 그것은 매우 불쾌한 버그였습니다. 다행스럽게도 테스트를 받았으며 버그를 해결하기 위해해야 ​​할 일을 정확히 알려주었습니다. 테스트 없이는 시스템을 구축하고 (버그가 해당 코드에 의존하는 다른 모듈을 감염시키는 경우) 버그가 발견 될 때까지이를 제대로 해결하는 것이 주요 과제였습니다.

TDD의 진정한 장점은 무모한 포기로 변화를 이룰 수 있다는 것입니다. 프로그래밍을위한 안전망과 같습니다. 공중 그네 예술가가 실수하여 넘어지면 어떻게 될지 생각해보십시오. 그물과 함께, 그것은 부끄러운 실수입니다. 그렇지 않으면 비극입니다. 마찬가지로 TDD는 골치 아픈 실수를 프로젝트 살해 재해로 전환하는 것을 방지합니다.

테스트 주도 개발을 옹호하거나 심지어 테스트 주도 설계 를지지하는 사람은 발견되지 않습니다 . 짚맨이라고 부르고 끝내자.

테스트가 시간과 노력의 낭비라고 말하는 TDD에 싫어하거나 감동을받지 않는 사람은 없습니다. 테스트가 응용 프로그램을 증명하지는 않지만 오류를 찾는 데 도움이됩니다.

이 두 가지 말로 소프트웨어에서 실제로 테스트를 수행하는 것과 관련하여 어느 쪽도 다른 일을하지 않습니다. 둘 다 테스트 중입니다. 둘 다 가능한 많은 버그를 찾기 위해 테스트에 의존하고, 테스트를 통해 소프트웨어 프로그램이 작동하고 당시에 발견 될 수 있는지 확인합니다. 단서가없는 사람은 테스트없이 소프트웨어를 판매하지 않으며, 단서가없는 사람은 테스트를 통해 버그없이 판매하는 코드를 렌더링 할 것으로 기대하지 않습니다.

따라서 TDD와 TDD와 TDD의 차이점은 테스트가 수행되는 것이 아닙니다. 테스트가 작성 될 때 차이점이 있습니다. TDD 테스트는 소프트웨어보다 먼저 작성됩니다. 비 TDD 테스트는 소프트웨어 이후 또는 소프트웨어와 함께 작성됩니다.

후자와 관련하여 내가 본 문제는 테스트가 원하는 결과 나 사양보다 작성되는 소프트웨어를 대상으로하는 경향이 있다는 것입니다. 테스트 팀이 개발 팀과 분리되어 있어도 테스트 팀은 소프트웨어를보고 소프트웨어를 사용하며 대상 테스트를 작성하는 경향이 있습니다.

프로젝트 성공을 연구하는 사람들이 몇 번이고 주목 한 것은 고객이 원하는 것을 얼마나 자주 배치하고 개발 사람들이 무언가를 작성하고 글을 작성하며 고객에게 "완료"라고 말할 때 그것은 고객이 요구 한 것과 완전히 다르지 않은 것으로 판명되었습니다. "하지만 모든 테스트를 통과했습니다 ..."

TDD의 목표는이 "순환 인수"를 위반하고 소프트웨어 자체가 아닌 소프트웨어를 테스트하는 테스트의 기초를 제공하는 것입니다. 테스트는 "고객"이 원하는 동작을 대상으로 작성되었습니다. 그런 다음 해당 테스트를 통과하도록 소프트웨어가 작성됩니다.

TDD는 이 문제를 해결하기위한 솔루션의 일부 입니다. 당신이 만드는 유일한 단계는 아닙니다. 그 밖의해야 할 일은 고객 피드백이 더 많고 더 자주 있는지 확인하는 것입니다.

내 경험상 TDD는 성공적으로 구현하기가 매우 어렵습니다. 자동화 소프트웨어가 제대로 작동하려면 자동화 된 테스트를 많이 수행해야하기 때문에 제품이 있기 전에 테스트를 작성하기가 어렵습니다. 단위 테스트에 익숙하지 않은 개발자가이를 수행하는 것도 어렵습니다. 몇 번이고 팀원들에게 테스트를 먼저 작성하라고했습니다. 실제로 한 번도 얻지 못했습니다. 결국 시간 제약과 정치는 더 이상 단위 테스트를하지 않기 위해 모든 노력을 파괴했습니다. 물론, 우연히도 설계가 우연히 심각하게 결합되어 원하는 경우에도 구현하는 데 막대한 비용이 소요될 수 있습니다. TDD는 궁극적으로 개발자에게 제공하는 것입니다.

먼저 디자인

TDD는 디자인을 건너 뛸 변명 이 아닙니다 . 나는 그들이 즉시 코딩을 시작할 수 있기 때문에 "민첩한"악 대차에서 많은 점프를 보았습니다. 진정한 민첩성은 폭포수 프로세스에 영감을 준 (다른 분야) 엔지니어링 우수 사례보다 훨씬 빠르게 통계 코딩을 할 수있게합니다.

그러나 조기 테스트

테스트가 설계를 주도한다고 말하는 것은 설계 단계가 완료되기 훨씬 전에 설계 단계에서 초기에 테스트를 사용할 수 있다는 것을 의미합니다. 이 테스트를 수행하면 회색 영역에 도전하고 제품이 완성되기 오래 전에 실제 환경과 맞 닿아 설계에 큰 영향을 미칩니다. 종종 디자인으로 돌아가서 이것을 고려하도록 조정해야합니다.

테스트와 디자인 ... 하나와 같은

제 생각에 TDD는 단순히 테스트를 위해 마지막에 수행 한 것이 아니라 디자인 의 필수 부분이 되도록 테스트를 제공 합니다. 점점 더 많은 TDD를 사용하기 시작하면 시스템을 설계 할 때 시스템을 파괴 / 파괴하는 방법에 대한 사고 방식을 갖게됩니다. 개인적으로 항상 테스트를 먼저 수행하지는 않습니다. 물론 인터페이스에서 명백한 (단위) 테스트를 수행하지만이 디자인이 깨질 수있는 새롭고 창의적인 방법을 생각할 때 생성하는 통합 및 사양 테스트에서 실질적인 이점을 얻을 수 있습니다. 방법을 생각하자마자 테스트를 코딩하고 결과를 확인합니다. 때로는 결과에 따라 살 수 있습니다.이 경우 테스트는 기본 빌드의 일부가 아닌 별도의 프로젝트에서 테스트를 이동합니다 (계속 실패하기 때문에).

그렇다면 누가 쇼를 운전합니까?

TDD에서 구동은 단순히 테스트가 설계에 큰 영향을 미치므로 실제로 테스트를 수행하고 있다고 느낄 수 있음을 의미합니다. 그러나 그것은 그것에 멈춰 섰다. 그리고 나는 당신의 걱정을 이해한다, 그것은 조금 무섭다. 누가 쇼를 운전 하는가?

당신 은 시험이 아니라 운전하고 있습니다. 테스트는 진행하면서 생성 한 내용에 대해 높은 수준의 신뢰를 얻으므로 견고한 근거 위에 있다는 것을 더 잘 알 수 있습니다.

시험이 견고하면 고체

정확히 , 따라서 TDD에서 구동됩니다. 시험이 전체를 주도하는 것은 그리 많지는 않지만, 시험은 당신이하는 일, 시스템을 설계하고 생각하는 방법에 큰 영향을 미치므로 사고 과정의 큰 부분을 시험과 대가로 위임 할 것입니다. 디자인에 큰 영향을 미칩니다.

그래,하지만 내가 다리로 그렇게하면 ...

소프트웨어 엔지니어링은 다른 엔지니어링 방식과는 매우 다릅니다. 실제로 소프트웨어 엔지니어링은 실제로 문학과 훨씬 더 공통적입니다. 하나는 완성 된 책을 가져다가 4 장을 찢을 수 있으며 두 장을 새로 대체하여 책에 다시 붙이면 여전히 좋은 책이 있습니다. 좋은 테스트와 소프트웨어를 사용하면 시스템의 모든 부분을 리핑하고 다른 시스템으로 교체 할 수 있으며 그렇게하는 데 드는 비용은 그다지 높지 않습니다. 실제로 테스트를 수행하여 디자인에 충분한 영향을 주도록 허용 한 경우 처음에 테스트를 작성하는 것보다 훨씬 저렴할 수 있습니다.이 대체로 인해 테스트에서 다루는 내용이 중단되지 않을 것이라는 확신이 있습니다.

그 sooo 좋은 방법이 올 때 항상 작동하지 않습니다?

테스트에는 건물과는 전혀 다른 사고 방식이 필요하기 때문입니다. 모든 사람이 전환 할 수있는 것은 아니며, 실제로 일부 사람들은 자신의 창조물을 파괴하려는 마음을 가질 수 없기 때문에 적절한 테스트를 만들 수 없을 것입니다. 이렇게하면 목표 메트릭에 도달하기에 충분한 테스트 또는 테스트가 거의없는 프로젝트가 생성됩니다 (코드 적용 범위를 염두에 두십시오). 그들은 경로 테스트와 예외 테스트를 만족 시키지만 코너 사례와 경계 조건을 잊어 버릴 것입니다.

다른 사람들은 디자인을 부분적으로 또는 전체적으로 테스트하는 테스트에 의존 할 것입니다. 그런 다음 각 구성원이 서로를 통합합니다. 디자인은 무엇보다도 커뮤니케이션 도구입니다. 우리가 지상에 말을 걸기 위해 설정 한 스테이크, 이것이 문과 창문이있는 곳이라는 스케치입니다. 이것 없이는 소프트웨어가 얼마나 많은 테스트를했는지에 관계없이 파멸됩니다. 통합과 병합은 항상 고통스럽고 최고 수준의 추상화에서 테스트가 부족합니다.

이 팀들에게 TDD가 갈 길이 아닐 수도 있습니다.

TDD를 사용하면 테스트하기 쉽지 않은 코드를 작성하지 않는 경향이 있습니다. 이것은 작은 것처럼 보일 수 있지만 테스트를 통해 버그를 리팩터링, 테스트, 재현 및 수정하는 것이 얼마나 쉬운 지에 영향을 미치므로 프로젝트에 큰 영향을 줄 수 있습니다.

또한 테스트에서 지원하는 더 팩토링 된 코드를 사용하면 프로젝트의 새로운 개발자가 더 빠르게 작업을 수행 할 수 있습니다.

나는 TDD를 그렇게 많이 연습하지 않더라도 이것에 대해 많이 생각하고 있습니다. 코드 품질과 다음 TDD 사이에 (강한?) 긍정적 상관 관계가있는 것 같습니다.

1) 첫 번째는 TDD가 코드에 "더 나은 품질"을 추가하는 TDD 때문이 아니라 TDD가 최악의 부품과 습관을 제거하고 간접적으로 품질을 높이는 것과 비슷하다는 것입니다.

나는 그것이 시험 자체가 아니라고 주장합니다. 그것은 시험을 작성 하는 과정입니다 . 나쁜 코드에 대한 테스트를 작성하는 것은 어렵고 그 반대도 마찬가지입니다. 그리고 프로그래밍하는 동안 이것을 머리 뒤쪽에 보관하면 많은 나쁜 코드가 제거됩니다.

2) 또 다른 관점 (이것은 철학적이다)은 주인의 정신 습관을 따르는 것이다. 당신은 그의 "외부 습관"(긴 수염이 좋다)을 따름으로써 주인이되는 법을 배우지 못하고, 그의 내부 사고 방식을 배워야하며, 이것은 어렵습니다. 그리고 어떻게 든 (초보자) 프로그래머가 TDD를 따르도록하고 그들의 사고 방식을 마스터의 방식에 더 가깝게 조정하십시오.

"쓰기 테스트 + 통과까지 리팩터링"접근 방식은 매우 반 엔지니어링합니다.

리팩토링과 TDD에 대한 오해가있는 것 같습니다.

코드 리팩토링 은 소프트웨어의 비 기능적 속성 중 일부를 개선하기 위해 외부 기능 동작을 수정하지 않고 컴퓨터 프로그램의 소스 코드를 변경하는 프로세스입니다.

따라서 코드가 전달 될 때까지 코드를 리팩터링 할 수 없습니다 .

그리고 TDD, 특히 단위 테스트 (다른 ​​테스트는 나에게 그럴듯 해 보이기 때문에 핵심 개선을 고려합니다)는 작동 할 때까지 구성 요소를 다시 디자인하는 것이 아닙니다. 구성 요소가 디자인 된대로 작동 할 때까지 구성 요소를 디자인하고 구현 작업을 수행합니다.

또한 정말 파악하는 것이 중요하다, 그 단위 테스트는 테스트에 관한 단위 . 항상 많은 것을 처음부터 작성하는 경향이 있으므로 그러한 단위를 테스트하는 것이 중요합니다. 토목 기사는 이미 자신이 사용하는 장치 (다른 재료)의 사양을 알고 있으며 작동 할 것으로 기대할 수 있습니다. 이것들은 종종 소프트웨어 엔지니어에게 적용되지 않는 두 가지 사항이며, 테스트를 거친 고품질의 구성 요소를 사용하기 때문에 사용하기 전에 장치를 테스트하는 것은 매우 공학적입니다.
토목 기사가 경기장을 덮기 위해 지붕을 만들기 위해 새로운 섬유 조직을 사용하려는 아이디어를 가지고 있다면, 필요한 사양 (예 : 무게, 침투성, 안정성 등)을 정의하여이를 단위로 테스트 할 것으로 예상합니다. 그런 다음 테스트가 완료 될 때까지 테스트하고 수정하십시오.

이것이 TDD가 작동하는 이유입니다. 테스트 된 유닛의 소프트웨어를 빌드 할 경우, 테스트 할 때 적용 범위가 넓다고 가정 할 때, 코드를 함께 연결하고 풀 코드에 문제가있을 것으로 예상 할 수 없을 때 훨씬 더 효과적입니다.

편집 :
리팩토링 의미 : 기능에 변화가 없습니다 . 단위 테스트 작성의 한 가지 요점은 리팩토링이 코드를 손상시키지 않도록하는 것입니다. 따라서 TDD는 리팩토링에 부작용이 없음을 보증하기위한 것입니다.
내가 말했듯이 단위는 시스템이 아닌 테스트 단위를 테스트하므로 입도는 정확하게 정의되기 때문에 입도는 관점의 주제가 아닙니다.

TDD는 훌륭한 아키텍처를 권장합니다. 모든 장치에 대한 사양을 정의하고 구현해야하므로 구현 전에 미리 설계해야하므로 생각과는 정반대입니다. TDD는 개별적으로 테스트 할 수있는 유닛의 생성을 지시하므로 완전히 분리됩니다.
TDD는 스파게티 코드에서 소프트웨어 테스트를 던져 파스타가 통과 할 때까지 교반한다는 의미는 아닙니다.

토목 공학과 달리 소프트웨어 공학에서 프로젝트는 일반적으로 끊임없이 발전합니다. 토목 공학에서는 x 톤을 운반 할 수 있고 시간당 n 대의 차량에 충분한 넓이 인 A 위치에 교량을 건설해야합니다.
소프트웨어 엔지니어링에서 고객은 기본적으로 어느 시점에서든 (완료 후) 결정을 내릴 수 있으며, 이중 데크 브리지를 원하고 가장 가까운 고속도로와 연결되기를 원하며 회사가 리프팅 브리지가되기를 원합니다. 최근에 범선을 사용하기 시작했습니다.
소프트웨어 엔지니어가되어 주어 디자인을 변경할 수 있습니다. 그들의 디자인에 결함이 있기 때문이 아니라 그것이 modus operandi이기 때문입니다. 소프트웨어가 제대로 엔지니어링 된 경우 모든 하위 수준 구성 요소를 다시 작성할 필요없이 상위 수준에서 다시 디자인 할 수 있습니다.

TDD는 개별적으로 테스트되고 분리 된 구성 요소로 소프트웨어를 구축하는 것입니다. 제대로 실행하면 요구 사항의 변경 사항이없는 것보다 훨씬 빠르고 안전합니다.

TDD는 개발 프로세스에 요구 사항을 추가하지만 다른 품질 보증 방법은 금지하지 않습니다. 물론 TDD는 공식 검증과 동일한 보안을 제공하지 않지만 공식 검증은 비용이 많이 들고 시스템 수준에서 사용하기가 불가능합니다. 그래도 원하는 경우 두 가지를 결합 할 수 있습니다.

TDD에는 시스템 수준에서 수행되는 단위 테스트 이외의 테스트도 포함됩니다. 설명하기 쉽지만 실행하기가 어렵고 측정하기가 어렵습니다. 또한, 그들은 그럴듯하다. 나는 그들의 필요성을 절대적으로 본다. 그러나 나는 그것들을 아이디어로 실제로 평가하지는 않는다.

결국 어떤 도구도 실제로 문제를 해결하지 못합니다. 도구는 문제를보다 쉽게 ​​해결합니다. 다음과 같은 질문을 할 수 있습니다 : 끌이 어떻게 훌륭한 건축에 도움이됩니까? 똑바로 벽을 만들 계획이라면 직선 벽돌이 도움이됩니다. 물론, 만약 당신이 그 도구를 바보에게 주면, 그는 아마도 그의 발을 통해 도구를 밟을 것입니다. 그러나 그것은 초보자에게 잘못된 보안을 제공하는 TDD의 결함이 아닌 한 끌의 잘못이 아닙니다. 좋은 시험을 쓰지 않는 사람.
결론적으로, TDD는 TDD가없는 것보다 훨씬 잘 작동한다고 말할 수 있습니다.

'사용자보다는 테스트가 요구 사항을 설정합니다.'라는 말이 마음에 들지 않습니다. TDD에서는 단위 테스트 만 고려하고 통합 테스트도 다루고 있다고 생각합니다.

소프트웨어의 기반을 구성하는 라이브러리를 테스트하는 것 외에도 사용자가 소프트웨어 / 웹 사이트 / 무엇과의 상호 작용을 다루는 테스트를 작성하십시오. 이들은 사용자로부터 직접 제공되며 오이 (http://cukes.info)와 같은 라이브러리는 사용자가 자연어로 테스트를 직접 작성할 수도 있습니다.

TDD는 또한 코드의 유연성을 장려합니다. 무언가의 아키텍처를 설계하는 데 영원히 투자한다면 나중에 필요한 경우 나중에 변경하기가 매우 어려울 것입니다. 몇 가지 테스트 작성으로 시작한 다음 해당 테스트를 통과하는 작은 코드를 작성하십시오. 더 많은 테스트를 추가하고 더 많은 코드를 추가하십시오. 코드를 근본적으로 변경해야하는 경우에도 테스트는 여전히 유효합니다.

브리지 및 자동차와 달리 단일 소프트웨어는 수명주기 동안 큰 변화를 겪을 수 있으며 테스트를 먼저 작성하지 않고 복잡한 리팩토링을 수행하는 것은 문제를 요구 합니다.

나는 당신이 잘못된 각도에서 첫 번째 지점에 접근하고 있다고 생각합니다.

이론적 인 관점에서, 우리는 고 장점을 점검함으로써 어떤 것이 효과가 있음을 증명하고 있습니다. 이것이 사용 된 방법입니다. 무언가 기능적임을 증명할 수있는 다른 많은 방법이있을 수 있지만, TDD는 비트 단위 접근 방식의 단순성으로 인해 자체적으로 확립되었습니다. 그것이 깨지지 않으면 작동합니다.

실제로 이것은 다음과 같이 잘못 해석됩니다. 이제 모든 술어를 만족시키기 위해 TDD를 성공적으로 적용한 후 다음 단계로 넘어갈 수 있습니다. 이 관점에서 TDD에 접근하면 "쓰기 테스트 + 패스 리 팩터까지 리 팩트"에 관한 것이 아니라 이제이 기능을 완료 한 것 입니다. 이제 다음 기능에 전적으로 가장 중점을두고 있습니다.

이것이 토목 공학에 어떻게 적용되는지 생각하십시오. 우리는 150000 명의 대중을 수용 할 수있는 경기장을 만들고 있습니다. 경기장의 구조적 무결성이 건전하다는 것을 입증 한 후에는 안전을 가장 먼저 만족 시켰습니다 . 화장실, 음식 판매대, 좌석 등과 같이 즉각적으로 중요한 다른 문제에 집중할 수 있습니다. 관객의 경험을보다 즐겁게 만들 수 있습니다. TDD에는 훨씬 더 많은 것이 있기 때문에 이것은 지나치게 단순화 된 것입니다. 그러나 중요한 점은 새롭고 흥미로운 기능에 집중하고 동시에 무결성을 유지하는 경우 가능한 최고의 사용자 경험을 제공하지 않는다는 것입니다. 두 경우 모두 반으로 얻습니다. 내 말은, 어떻게 정확히 어떻게 알 수 있니많은 화장실과 150000 명을위한 장소는 어디입니까? 나는 내 인생에서 경기장이 무너지는 것을 거의 보지 못했지만 너무 많은 시간 동안 반 시간 동안 줄을 서서 기다려야했습니다. 화장실 문제는 더 복잡 할 것이며 엔지니어가 안전에 더 적은 시간을 할애 할 수 있다면 결국 화장실 문제를 해결할 수있을 것입니다.

두 번째 요점은 우리가 절대적인 것이 바보 노력 이고 행크 무디가 존재하지 않는다고 이미 동의했기 때문에 관련 이 없습니다 (그러나 나는 그것에 대한 참조를 찾을 수없는 것 같습니다).

소프트웨어 엔지니어링의 TDD는 응용 프로그램에서의 오류 처리가 로그 처리 및 진단뿐만 아니라 오류 처리의 모범 사례와 같은 방식으로 좋습니다 (오류 처리의 일부 임에도 불구하고).

TDD는 소프트웨어 개발을 시행 착오 코딩으로 줄이는 도구로 사용되지 않습니다. 그러나 여전히 대부분의 프로그래머는 런타임 로그를 보거나 디버거에서 예외를 보거나 개발 단계에서 하루 종일 앱을 코딩 / 컴파일 / 실행하는 것으로 구성된 실패 / 성공의 다른 징후를 사용합니다.

TDD는 개발자로서 생산성을 높이기 위해 이러한 단계를 공식화하고 자동화하는 방법입니다.

1) 소프트웨어 엔지니어링을 브릿지 구조와 비교할 수는 없습니다. 브릿지 구조의 유연성은 소프트웨어 프로그램 설계의 유연성과 전혀 다릅니다. 브릿지를 구축하는 것은 동일한 프로그램을 반복해서 손실이 많은 머신에 쓰는 것과 같습니다. 소프트웨어처럼 브릿지를 복제하고 재사용 할 수 없습니다. 각 브리지는 고유하며 제조해야합니다. 자동차 및 기타 디자인도 마찬가지입니다.

소프트웨어 엔지니어링에서 가장 어려운 것은 결함을 재현하는 것입니다. 브리지가 실패하면 일반적으로 무엇이 잘못되었는지 쉽게 판단 할 수 있으며 이론적으로는 오류를 재현하는 것이 쉽습니다. 컴퓨터 프로그램이 실패하면 시스템을 결함 상태로 만드는 복잡한 이벤트 체인 일 수 있으며 오류의 위치를 ​​판별하기가 매우 어려울 수 있습니다. TDD 및 단위 테스트를 통해 소프트웨어 구성 요소, 라이브러리 및 알고리즘의 견고성을 쉽게 테스트 할 수 있습니다.

2) 약한 단위 테스트와 얕은 테스트 사례를 사용하여 시스템에 스트레스를주지 않으면 서 잘못된 신뢰감을 구축하는 것은 나쁜 습관입니다. 시스템의 아키텍처 품질을 무시하고 테스트를 수행하는 것은 물론 나쁘다. 그러나 건물을 구하기 위해 초고층 빌딩이나 다리를 사기 위해 재료를 절약하고 청사진을 따르지 않는 것은 항상 나쁘고 항상 발생합니다 ...

버그를 빨리 발견하면 버그를 수정하는 데 드는 비용이 적으므로 TDD만으로도 가치가 있습니다.

TDD는 실제로 테스트에 관한 것이 아닙니다. 그리고 그것은 좋은 테스트를위한 대체물이 아닙니다. 그것이 당신에게주는 것은 잘 생각하고 소비자가 소비하기 쉽고 나중에 유지 보수 및 리팩토링하기 쉬운 디자인 입니다. 이로 인해 버그가 줄어들고 더 잘 적응할 수있는 소프트웨어 디자인이 만들어집니다. TDD는 또한 귀하의 가정을 생각하고 문서화하는 데 도움이되며 종종 그 중 일부가 잘못되었음을 발견합니다. 프로세스 초기에 이러한 정보를 찾을 수 있습니다.

또한 좋은 부작용으로 리팩토링이 소프트웨어의 동작 (입력 및 출력)을 변경하지 않도록하기 위해 실행할 수있는 대규모 테스트 모음이 있습니다.

간단한 답변을 드리겠습니다. 일반적으로 TDD는 단위 테스트처럼 잘못된 방식으로 보입니다. 좋은 테크 토크 비디오를 본 후 최근까지 단위 테스트를 이해하지 못했습니다. 본질적으로 TDD는 다음과 같은 일을 원한다고 말합니다. 반드시 구현해야합니다. 그런 다음 평소와 같이 나머지 소프트웨어를 설계합니다.

라이브러리를 디자인하기 전에 라이브러리의 사용 사례를 작성하는 것과 같습니다. 라이브러리에서 유스 케이스를 변경할 수 있고 TDD를 사용하지 않을 수도 있습니다 (API 디자인에는 TDD를 사용합니다). 또한 더 많은 테스트를 추가하고 테스트가받을 수있는 거친 입력 / 사용을 생각하는 것이 좋습니다. 라이브러리 또는 API를 작성할 때 무언가를 변경하면 무언가를 깨뜨렸다는 것을 알아야 할 때 유용합니다. 대부분의 일상적인 소프트웨어에서 버튼을 누르는 사용자에 대한 테스트 사례가 필요한 이유 또는 CSV 목록 또는 한 줄에 하나의 항목이있는 목록을 수락하려는 경우 왜 귀찮게하지 않습니까? 따라서 TDD를 사용해서는 안됩니다.

구조 엔지니어링이 구체적 일 때 소프트웨어는 유기적입니다.

다리를 지을 때 다리는 남아있을 것이며 짧은 시간 안에 다른 것으로 발전하지는 않을 것입니다. 몇 달과 몇 년에 걸쳐 개선 될 것이지만, 소프트웨어 에서처럼 몇 시간과 며칠은 아닙니다.

독립적으로 테스트 할 때 일반적으로 사용할 수있는 두 가지 유형의 프레임 워크가 있습니다. 제약 된 프레임 워크 및 제약되지 않은. 제한되지 않은 프레임 워크 (.NET)를 사용하면 액세스 수정 자에 관계없이 모든 것을 테스트하고 대체 할 수 있습니다. 즉, 개인 및 보호 된 구성 요소를 스텁하고 조롱 할 수 있습니다.

내가 본 대부분의 프로젝트는 제한된 프레임 워크 (RhinoMocks, NSubstitute, Moq)를 사용합니다. 이러한 프레임 워크로 테스트 할 때는 런타임에 종속성을 주입하고 대체 할 수있는 방식으로 애플리케이션을 설계해야합니다. 이것은 느슨하게 결합 된 디자인이 있어야 함을 의미합니다. 느슨하게 결합 된 디자인 (올바로 수행 된 경우)은 더 나은 관심 분리를 의미하며 이는 좋은 일입니다.

요약하면, 나는 이것의 배후에서 생각하면 디자인이 테스트 가능하다면 느슨하게 결합되어 있고 관심사가 잘 분리되어 있다고 생각합니다.

참고로, 실제로 테스트 할 수는 있지만 객체 지향 디자인 관점에서 제대로 작성되지 않은 응용 프로그램을 보았습니다.

왜 TDD가 작동합니까?

그렇지 않습니다.

설명 : 자동화 된 테스트는 테스트가없는 것보다 낫습니다. 그러나 개인적으로 대부분의 단위 테스트는 일반적으로 긴장을 풀기 때문에 낭비 적이라고 생각합니다 (예 : 테스트중인 실제 코드에서 명백한 것을 말함). 일관성이 있고 중복되지 않고 모든 국경 사건 (일반적으로 오류가 발생하는 경우)을 포괄하지 못한다는 것을 쉽게 증명할 수 없습니다 ).

그리고 가장 중요한 것은 : 우수한 소프트웨어 디자인은 많은 애자일 / TDD 전도자에 의해 광고되는 테스트에서 마술처럼 빠지지 않습니다. 그렇지 않다고 주장하는 모든 사람은이를 입증하는 동료 검토 과학 연구에 대한 링크를 제공하거나 적어도 코드 변경 내역으로 TDD의 이점을 잠재적으로 연구 할 수있는 일부 오픈 소스 프로젝트에 대한 참조를 제공하십시오.