이론적으로 만 TDD

약 1 년 전에 나는 9 개월의 휴식을 취할 수있을만큼 운이 좋았다. 나는 그 시간에 C # 기술을 연마하기로 결정했습니다. 나는 많은 프로젝트를 시작했고 TDD를 따르도록 강요했다.

상당히 깨달은 과정이었습니다.

처음에는 힘들었지 만 시간이 지남에 따라 더 테스트 가능한 코드를 작성하는 방법을 알게되었고 (이것은 더 많은 SOLID 코드 인 경향이 있음) 그 과정에서 OO 디자인 기술도 향상 시켰습니다.

이제 나는 노동력으로 돌아 왔고 이상한 것을 눈치 m습니다.

나는 TDD를 따르지 않는 것을 선호합니다.

TDD로 인해 속도가 느려지고 실제로 깨끗한 응용 프로그램을 디자인하기가 더 어려워졌습니다.

대신, 나는 약간 (대규모) 다른 접근법을 채택했습니다.

1. 작업의 수직 조각을 선택
2. 작동하는 프로토 타입 개발
3. 모든 것이 멋지고 깔끔해질 때까지 리팩터링
4. 내가 작성한 아름다운 SOLID 및 테스트 가능한 코드에 감사드립니다.

1 단계가 "테스트 대상의 공개 표면을 정의"하지 않았고 2 단계가 "공개 영역에서 bejesus를 테스트"하지 않았 음을 알 수 있습니다. 또한 테스트와 관련된 단계가 없음을 알 수 있습니다. 테스트 가능한 코드를 작성하고 있지만 아직 테스트하지는 않았습니다.

이제 실제로 어떤 종류의 테스트도 수행하지 않았다는 것을 분명히하고 싶습니다. 내가 쓰는 코드가 작동합니다 . 수동으로 테스트하기 때문에 작동합니다.

또한 모든 자동화 된 테스트를 능가하지는 않는다는 것을 분명히하고 싶습니다. 이것은 내 프로세스가 다른 곳입니다. 그리고 이것이 내가이 질문을하는 이유입니다.

이론적으로 TDD. 실제로는 아닙니다.

내 프로세스는 약간 발전했으며 TDD와 테스트가없는 것 사이에서 균형을 잡았으며 매우 생산적이며 합리적으로 안전합니다. 다음과 같이 진행됩니다.

1. 테스트를 염두에두고 작동하는 수직 작업 조각을 구현하지만 테스트를 작성하지 마십시오.
2. 길을 내려간 경우 (예 : 한 달 후) 해당 슬라이스를 수정해야합니다.
   1. 작업 단위가 올바른지 확인하는 단위 테스트, 통합 테스트, 동작 테스트 등 작성
   2. 코드 수정
3. 해당 슬라이스를 수정할 필요가없는 경우
   1. 아무것도하지 마세요

코드를 작성 하기 전에 코드를 수정 하기 전에 테스트 작성의 부담을 간단히 변경함으로써 훨씬 더 많은 작업 코드를 생성 할 수있었습니다. 그리고 테스트를 작성하려고 할 때 훨씬 적은 수의 글을 쓰지만 거의 많은 부분을 차지합니다 (높은 ROI).

이 프로세스가 마음에 들지만 확장이 잘되지 않을까 걱정됩니다. 이 테스트의 성공은 개발자가 변경하기 전에 테스트 작성에 대해 부지런한 노력을 기울입니다. 그리고 그것은 꽤 큰 위험 인 것 같습니다. 그러나 TDD는 매우 위험합니다.

그래서 [BT] DD 지옥에 가겠습니까, 아니면 이것이 일반적인 형태의 실용적인 코딩 및 테스트입니까?

이런 식으로 계속 일하고 싶습니다. 이 프로세스를 장기적으로 작동 시키려면 어떻게해야합니까?

나는 프로젝트의 유일한 개발자이며 요구 사항 수집, 디자인, 아키텍처, 테스트, 배포 등 모든 것을 담당합니다. 이것이 프로세스가 작동하는 이유라고 생각합니다.

프로세스가 장기적으로 작동하게하려면 코드를 작성할 때 테스트를 작성합니다.

귀하의 접근 방식과 모순되는 것처럼 보일 수 있습니다. 그러나 당신은 질문을 제기하여 내가 당신에게 내 테이크를 줄 것입니다 :

코드 전에 테스트를 작성할 필요가 없습니다. 그 순결을 잊어 버리십시오. 그러나 당신은 시험을 쓰고 싶은 주변의 시간을.
코드가 작동하면 약간 조정하고 버그가 발생했습니다 (여기서는 시간 척도에 대해 이야기하고 있습니다). 그러면 코드가 수행하는 작업에 대한 최대한의 지식을 얻을 수 있습니다. 지식을 포착하는 테스트를 작성하기에 좋은시기입니다.

이것을 나중에 그대로 두는 것은 시간이 지남에 따라 지식이 자연적으로 감소한다는 것을 의미합니다.

또한 귀하가 떠나야하고 다른 사람이 귀하를 인계해야하는 것은 무엇을하는지 (시험을 통해) 문서화하지 않았다는 즉각적인 기술적 부채를 갖지 않을 것임을 의미합니다.

무엇보다도 "언젠가"오지 않을 수 있습니다. 버스에 부딪 히거나 새로운 모험을 위해 버스에 탑승 할 수 있습니다.

마지막으로, 수동 테스트는 확장되지 않으며 최종 사용자가 사용하는 모든 장치를 다루지는 않습니다.

TDD는 100 % 구현하기가 어렵지만 접근 방식에 결함이 있습니다.

1. 작동하는 수직 작업 조각 구현

   1.1 1 년 패스 ....

   1.2 새로운 개발자가 프로젝트 작업을 시작합니다

2. 해당 슬라이스를 수정해야하는 경우

   2.3 '클린 코딩'스타일 메소드 이름 및 매개 변수 'GetUnicorn (colourOfUnicorn)'구문 분석

   2.4 XML 주석 읽기 '골드 유니콘을 얻습니다 (승차 용) (obvs)'

   2.5 오리지널 개발자 사냥

   2.6 코드가 무엇을해야하는지 기억하기를 바란다

   2.7 모든 것을 설명하도록하라

3. 단위 테스트, 통합 테스트, 행동 테스트 등 쓰기 만하면 일이 올바른지의 조각을 보장을

4. 코드 수정

수정이 필요할 때 단위 테스트가 실제로 그 가치를 나타내는 지 확인하는 것이 옳다고 생각합니다.

Daniel Hollinrake와 Ewan에 동의합니다. 테스트 전용 수정 기능이 지금까지 작동하는 첫 번째 요점은 다음과 같습니다.

I am the sole developer on my projects and I am responsible for everything

아마도 두 번째 요점은 다음과 같습니다.

you're producing nice clean code

TDD가 유일한 프로그래머에게 큰 생산성 향상을 가져다 줄 것이라고 생각하지 않으며 이미 깨끗한 코드를 작성하는 경우 코드 품질이 크게 향상되지 않을 수 있습니다.

그러나 TDD는 특히 열악한 / 경험이없는 / 사용하지 않는 프로그래머의 코드 품질을 향상시킬 것입니다. 코드를 수정 한 사람이 원래 또는 몇 개월 동안 코드를 작성한 사람과 동일하지 않은 경우 더욱 그렇습니다.

다시 말해서, TDD는 코드 품질을 향상시키는 좋은 방법이라고 생각합니다. 솔로 작업보다 훨씬 일반적인 상황입니다.

나에게 중요한 것은 이것으로 보인다 :

나는 프로젝트의 유일한 개발자이며 요구 사항 수집, 디자인, 아키텍처, 테스트, 배포 등 모든 것을 담당합니다. 이것이 프로세스가 작동하는 이유라고 생각합니다.

이것은 당신을 위해 작동하며 멋진 깨끗한 코드를 생산하고 있습니다 (나는 가정합니다!). 내가해야 할 유일한 것은 다른 개발자가 들어 와서 변경을 확신 할 수 있도록 테스트 장치를 만드는 것입니다. 또한 테스트 하네스는 코드 동작의 일관성을 보장합니다.

나는 당신의 접근 방식이 내 것과 비슷하다고 생각합니다. 나는 보통 내 프로젝트의 유일한 개발자입니다. TDD에 대한 감사 덕분에 더 작은 기능과 더 깨끗한 코드를 작성할 수 있었지만 코드를 테스트 하네스로 작성하는 동안 테스트를 추가했습니다. 그렇게하면 코드가 발전하고 기능이 변경됨에 따라 변경을 확신 할 수 있습니다.

테스트를 작성하는 두 번째 이유는 테스트 형식이라고 생각하기 때문입니다. 함수가 작성된 이유에 대한 나의 추론을 설명 할 수 있습니다. 그러나 여기서는 행동 주도 개발에 대해 더 많이 생각하고 있습니다.

단위 테스트는 코드 유지 관리 문제를 해결하는 것입니다. TDD를 사용하지 않고 코드를 작성하는 것이 더 빠르다고 말하는 사람들이 있지만 테스트를 작성하지 않고도 더 많은 새 코드를 작성할 수 있다는 사실에 놀라지 않습니다.

테스트를 변경하기 직전에 테스트 작성 연습에서 볼 수있는 문제 :

나는 종종 서둘러 변경해야한다

필요할 때 테스트 만 작성하여 전체 시간을 절약 할 수 있지만 모든 시간이 동일하지는 않습니다. 내가 위기 모드에있을 때 1 시간을 절약하기 위해 테스트를 작성하는 데 2 ​​시간을 소비하면 그만한 가치가 있습니다.

코드를 작성하는 동시에 테스트를 작성하는 것이 더 쉽습니다.

단위 테스트를 올바르게 작성하려면 테스트중인 코드를 이해해야합니다. 단위 테스트를 이해하는 연습으로 자주 사용하지만 기존 코드를 이해하는 데 시간이 걸리기 때문에 기존 코드의 단위 테스트에 많은 시간이 소요될 수 있습니다. 코드를 작성할 때 테스트를 작성하는 것과는 대조적으로 이미 코드를 이해했기 때문에 훨씬 빨리 찾을 수 있습니다. 방금 코드를 작성했습니다!

레거시 코드의 Michael Feathers 정의는 테스트가없는 코드입니다. 자신의 정의에 동의하는지 여부에 관계없이 기존 코드를 수정하는 비용의 상당 부분이 여전히 예상대로 작동하는지 확인하는 경우가 많으며 종종 예상되는 동작이 무엇인지 명확하지 않습니다.

작문 단위 테스트는 올바른 행동이 무엇인지에 대한 이해를 인코딩하고 행동이 여전히 올바른지 확인하는 "미래"에 대한 쉬운 방법을 제공함으로써 비용을 상쇄합니다.

이것은 좋은 질문이며 FWIW 나는 내 두 센트를 던질 것입니다.

약 1 년 전에 저는 코드를 작성 하기 전에 반드시 테스트 를 작성해야하는 것이 아니라 일반적으로 테스트를 작성하도록 강요 한 메커니즘을 가진 플랫폼 인 Salesforce에서 코딩을하고있었습니다 .

작동 방식은 시스템에서 테스트를 작성하도록 강제하고 테스트 한 코드 줄 수를 백분율로 계산하는 것입니다. 프로덕션 인스턴스 전체의 모든 코드가 75 % 미만으로 테스트 된 경우 .. Salesforce가 더 이상 작동하지 않습니다.

결과적으로 Salesforce에서 작업을 수행 할 때마다 테스트를 작성하거나 업데이트해야했습니다. 이것이 Salesforce의 시장 점유율에 큰 영향을 미칠 것이라 확신하지만 개발자의 수명면 에서는 엉덩이에 엄청난 고통이있었습니다 .

많은 시간 당신은 단지 작은 티켓을 통해 얻으려고 노력하고 테스트했다가 와서 그냥하는 기능에 대해, 개발 시간을 두 배로 알고 작품.

그런 다음 TDD의 어색한 개념이 부서를 통해 데이터베이스로 바로 스윕되었습니다. 우리의 건축가는 IT 부서의 모든 측면에 철저한 테스트를 진행하고자했습니다. 엉덩이에 약간의 통증, 엉덩이에 더 큰 통증을 만나십시오.

당시 TDD는 실제로 의미가 없었으며 지금도 여전히 그렇지 않습니다. 현재 역할에서 작성한 많은 기능은 위에서 언급 한 것과 유사한 메커니즘으로 작동합니다. 세로 슬라이스는 작동 할 때까지 수정합니다. 내가 그 오래된 역할을했지만 지금도 실제로 실제로 코드를 작성할 때까지 코드가 무엇을하는지 알지 못하기 때문에 테스트를 작성하여 코드를 구동 할 수 있다는 생각만으로 작성하려고합니다. 나에게는 이해가되지 않으며, 성가 시며, 대부분 시간 낭비입니다.

모든 것이 말했듯이, 테스트는 세상에서 모든 것을 올바르게 만드는 훌륭하고 마술적인 것입니다 . 코드가 정확하고 앱이 생각하는대로 작동하며 일반적으로 모든 것이 원활하게 이루어 지도록합니다. 문제는 코드를 작성하기 전에 테스트를 작성하든 코드를 작성하든 테스트에 얼마나 많은 시간을 할애 하느냐가 아닙니다. 그것은 적어도 내 소프트웨어 개발 경험에서 실제 문제입니다. 테스트에는 시간과 돈이 필요하며 경쟁 관계의 틀 안에서해야합니다.

그리고 일반적으로 나는 당신에게 동의합니다. 실제로 TDD는 약간 어색하고 번거 롭습니다. 이 시점 에서 현재 상황에서 가장 잘 작동하는 것을 명심 해야합니다 . 중요한 코드를 작성하는 경우 일반적인 테스트를 거쳐야합니다. 시간이 있다면 TDD를 사용 해보고 프로세스에 어떤 것이 추가되는지 확인하십시오.

나는 당신의 접근 방식을 추천 할 수 없습니다.

귀하의 접근 방식을 사용하면 예를 들어 다음과 같습니다 (집은 응용 프로그램입니다).

1. 나는 약간의 지식을 가진 벽돌공 또는 초보자로서 가족을위한 집을 짓기 시작합니다.
2. 나는 어린이 방, 객실과 같은 요구 사항을 알고 내 "시제품"집을 짓기 시작합니다.
3. 몇 번 후에 "시제품"집이 완성되었습니다.
4. 구조가 수동으로 충분히 안정적인지 확인하기 시작합니다. 그래서 나는 많은 무게를 들고 1 층의 다른 방으로 가져옵니다. 가족과 함께 방에 앉아있을 때 천장이 깨지지 않습니다. 그러나 그것은 깨지고 리팩토링을 시작합니다. 먼저 모든 덩어리를 청소하십시오. 새로 빌드하고 충분히 안정 될 때까지 수동으로 다시 테스트하십시오.
5. 나는 가족과 함께 이사보다. 모두 괜찮습니다.
6. 나방 후에 내 사촌과 부모님이 우리를 방문하려고합니다. 그러나 그들이 우리 집에 들어가기 전에 건축가와 토목 기술자에게 비용을 지불해야 1 층에있는 방 중 하나에 앉았을 때 천장이 깨지지 않도록해야합니다.
7. 건축가와 토목 기사는 시작할 것이 없기 때문에 많은 작업을 수행합니다. 그래서 그들은 내 집으로 가서 어떻게 건축해야하는지 살펴 봐야합니다.
8. 그리고 다시 그것은 충분히 안정적이지 않습니다. 그래서 그들은 1 층의지면을 리팩토링해야합니다.
9. 그러나 그 후 모든 것이 잘되고 모두 안전하게 내 집에 들어갈 수 있습니다.

그래서 당신의 접근 방식으로 집을 짓기 전에 당신의 접근 방식에는 많은 시간과 지식이 필요합니다. 또는 시간이 많이 걸립니다! 또한 요구 사항이 변경되었을 때 코드에 대한 다른 쓰기 테스트를 허용하는 것은 훌륭한 신사가 아닙니다.

따라서 "프로토 타입"을 프로그래밍하지 않고 리팩토링을 시작하는 것보다 더 나은 방법이 있습니다. 프로토 타입을 프로그래밍하는 대신 다음과 같이 애플리케이션의 UML을 사용하여 디자인하십시오.

1. UseCase 다이어그램을 작성하십시오. draw.io 를 사용 하여 시작할 수 있습니다 .
2. UseCases를 기반으로 EPK 다이어그램을 작성하여 동작을 판별하십시오. (응용 프로그램의 동작) 코딩 된 프로토 타입을 리팩터링하는 것보다 리팩터링하는 것이 더 빠릅니다. 특히 초보자 일 때.
3. 클래스 다이어그램을 작성하십시오. (응용 프로그램의 구조)
4. 동작 구현에서 문제가 발생할 수있는 위치를 결정하십시오.
5. 이 동작을 구현할 수있는 방법을 결정하려면 10 또는 20 줄의 코드로 간단한 프로토 타입을 작성하십시오. 초보자에게 좋습니다. 또는 튜토리얼을보고 다른 예제 응용 프로그램의 소스 코드를 살펴보십시오. 그들이 어떻게 해결했는지.
6. 코딩 시작보다. UseCase의 성공 테스트를 주먹으로 묶으십시오. 이것은 다른 방식으로 수행 될 수 있습니다. 먼저 테스트 및 UseCase에 필요한 모든 구조를 작성하십시오. Enterprise Architekt를 사용 하면 구조를 생성 할 수 있습니다. 다이어그램을 기반으로합니다. 또는 테스트를 배선하는 동안 구조를 만듭니다. 따라서 컴파일 오류가 나타나지 않습니다. 여기에서는 응용 프로그램의 동작을 테스트하기 만하면됩니다. 사용 사례.
7. UseCase의 동작을 구현하십시오.
8. 성공한 UseCases가 시작되면 예외 테스트를 작성하십시오. 테스트가 유효 할 때 녹색을 볼 때 항상 기분이 좋습니다.)
9. 그리고 당신은 끝났습니다.

물론이 방법에는 UML에 대한 지식이 필요하지만 배우는 것이 빠릅니다. 또한 IDE에서보다 클래스 이름을 바꾸거나 다이어그램에서 화살표를 이동하는 것이 항상 빠릅니다. 그러나 테스트 프레임 워크의 사용법을 배우는 것은 처음에는 더 소진 될 것입니다. Best는 오픈 소스 프로젝트의 테스트를 실행하고 작동 방식을 살펴 보는 데 있습니다. 그러나 테스트 기반 응용 프로그램을 사용하면 다음 응용 프로그램이 훨씬 빨라집니다. 그리고 모든 것이 잘 작동한다는 것을 아는 것이 좋은 느낌이라고 생각합니다.

그래서 나는 초보자들에게는 시간이 많이 걸리고 결국에는 좋지 않기 때문에 접근 방식에 투표하지 않았습니다. 구조와 동작 사이의 경계를 깨끗하게 유지하려면 도메인 기반 디자인을 사용하고 패키지 아래에 두 개의 패키지 (하나의 패키지로 명명 된 구조와 다른 하나의 명명 된 동작)로 도메인 정렬을 사용할 수 있습니다. 또한 테스트를 위해. 간단한 예제 는 자바로 작성된 이 예제 를 확인하십시오 .

내가 쓰고있는 코드가 작동합니다. 수동으로 테스트하기 때문에 작동합니다.

약간의 변경 후 조건의 가능한 모든 분기를 수동으로 테스트 했습니까? 수동 테스트의 피드백 루프 소요 시간 자동화 된 테스트를 통해 피드백 루프와 얼마나 가까운 지 확인하십시오.

자동화 된 테스트 (테스트 우선은 중요하지 않음)는 코드에 대해 더 빠른 피드백 루프를 제공하여 빠르게 진행합니다.

6 개월 후에 수동으로 어떤 조건을 테스트해야한다는 것을 기억하십니까?-모든 중요한 조건을 테스트 할 것이라고 말하지 마십시오. 문서 / 설명을 작성하는 것은 테스트를 작성하는 것과 같습니다 (실행 가능한 문서).

• 작업의 수직 조각을 선택

• 작동하는 프로토 타입 개발

• 모든 것이 멋지고 깔끔해질 때까지 리팩터링

그리고 다시 : 리팩토링하는 동안 리팩토링의 영향을받는 모든 논리를 수동으로 테스트 했습니까? 리팩토링 변경을 테스트하는 데 시간이 얼마나 걸립니까? 리팩토링으로 일부 코드가 중단되면 중단 이유를 찾는 데 얼마나 오래 걸립니까?

• 내가 작성한 아름다운 SOLID 및 테스트 가능한 코드에 감사드립니다.

아름답고 깨끗한 코드는 매우 주관적입니다. 코드는 깨끗하고 합리적입니다. 코드를 실제로 읽고 이해하고 테스트 할 수 있는지 확인하는 가장 좋은 방법은 다른 개발자가 작성한 테스트 및 코드 검토입니다.

당신은 코드를 다루는 개발자 일뿐이기 때문에 매우 생산적인 방법을 찾았습니다.이 프로젝트에서 일하기 시작했기 때문에 (제 생각 에이 프로젝트는 몇 살입니까? 6-8 개월?)
당신은 여전히 ​​당신이 쓴 모든 것을 기억하고 가능한 문제의 원인을 인식 할 수 있습니다. 나는 당신이 아무것도 잊어 버리지 않기를 원하기 때문에 프로젝트를 시작한지 ​​2 년에서 3 년 후에 테스트를 시작할 것이라고 확신합니다.

실수를하지 않으면 실제로 테스트가 필요하지 않습니다. 대부분의 개발자는 실수를 저 지르지 만, 절대 그렇게하지 않으면 앞으로 실수하지 않을 것이라고 확신하며 (그리고 프로젝트에서 유일하게 유일무이합니다), 테스트 작성에 시간을 낭비 할 이유가 없습니다.

그러나 코드를 변경할 때 테스트 작성을 제안하기 때문에 솔루션이 반쯤입니다. 그러나 동시에 테스트 할 코드 부분을 결정할 때 실수하지 않을 것이라고 가정합니다. 변경 사항이 영향을 줄 수있는 영역을 항상 완벽하게 이해하는 경우에만 작동합니다. 나는 많은 일반적인 개발자 (물론 아닙니다!)가 변화를 경험 한 적이 있다고 생각합니다. 실수로 인해 예기치 않은 테스트가 실패합니다.

물론 좋은 아키텍처, SOLID 원칙 등은 이러한 상황을 방지해야하지만 대부분의 개발자는 완벽하지 않기 때문에 시스템 전체의 테스트가 중요합니다.