단위 테스트를 작성하기 전에 코드를 작성할 때의 단점은 무엇입니까?

나는 항상 단위 테스트를 작성하고 코드 작성을 시작해야한다는 권고를 보았습니다. 그러나 다른 방법으로가는 것이 훨씬 편안하다고 생각합니다. 코드를 작성한 다음 단위 테스트를 작성하십시오. 실제 코드를 작성한 후에 훨씬 명확하게 느껴지기 때문입니다. 코드를 작성한 다음 테스트를 수행하는 경우 테스트 가능한 디자인을 만드는 데 많은 노력을 기울이더라도 테스트 가능하도록 코드를 약간 변경해야 할 수도 있습니다. 반면에 테스트를 작성한 다음 코드를 작성하면 테스트가 코드가 형성 될 때마다 자주 변경됩니다.

테스트 작성을 시작하고 코딩으로 넘어 가기위한 많은 권장 사항을 볼 때 다른 방법으로 코드를 작성하고 단위 테스트를 수행하면 어떤 단점이 있습니까?

빨간색이 답입니다. 레드는 TDD의 레드 그린 리 팩터 사이클에서 얻을 수없는 것입니다. 먼저, 실패한 테스트를 작성하십시오. 실패를 조심하십시오. 그것은 당신의 빨간색이며, 중요합니다. 그것은 말합니다 : 나는이 요구 사항을 가지고 있으며 내 코드가 만족스럽지 않다는 것을 알고 있습니다. 따라서 2 단계 (녹색)로 이동하면 코드가 현재 해당 요구 사항을 충족하고 있음을 알 수 있습니다. 요구 사항을 충족하는 방식으로 코드베이스를 변경했음을 알고 있습니다.

코드를 기반으로 코드 이후에 개발 된 요구 사항 (테스트)은 그러한 확신과 신뢰를 박탈합니다.

코드를 작성한 다음 테스트를 수행하면 코드가 사양을 충족하는지 확인하기 위해 테스트를 작성하는 대신 코드를 통과하도록 테스트 작성의 함정에 빠지기가 너무 쉽습니다.

그것은 분명히 일을하는 유일한 방법은 아니며 소프트웨어를 개발하는 "최상의"방법은 없습니다. 테스트 사례를 개발하기 위해 많은 선행 작업을 수행하면 제안 된 아키텍처에 결함이 있는지 나중에 알지 못합니다. 먼저 코드를 개발하면 더 빨리 실행하여 더 적은 침몰로 다시 디자인 할 수 있습니다 노력.

실제로, 사람들은 약어에있는 다른 두 글자를 잊지 만 TDD는 테스트에 관한 것입니다. 여기에서 읽을 수있는 것 : T 또는 TDD가없는 TDD는 Testing이 아닙니다 .

문제는 TDD로 단단히 짜여진 많은 다른 것들을 배웠다는 것입니다. 먼저 테스트하면 문제가되지 않습니다. 중요한 것은 소프트웨어 디자인에 대한 것 입니다.

단위 테스트를 "올바른 방법" 으로 작성할 수 있도록 ( 즉, 격리되고 빠르며 자동화 된 상태로), 코드를 쉽게 만드는 방식으로 코드를 배열하는 방법에 대해 다시 생각해야한다는 점을 잘 알고있을 것입니다 테스트합니다.

개인적으로 나는 그런 글이 있다는 것을 몰라도 SOLID 원리 를 배웠습니다 . 단위 테스트를 작성하면 클래스를 다시 작성해야하기 때문에 테스트하기가 너무 복잡하지 않기 때문입니다. 그것은 다음과 같은 것들로 이어졌습니다.

• 이해가 안되거나 개인 메소드에 상주하는 기능을 별도의 클래스로 옮겨서 별도로 테스트 할 수있었습니다. (단일 책임 원칙).
• 큰 상속 구조를 피하고 대신 구성으로 구현을 확장해야했습니다 (Open-Closed 원칙에서 두드러짐).
• 나는 상속에 대해 똑똑해야했고, 공유 할 수있는 스텁 메소드 (Liskov Substitution Principle)를 사용할 수있는 공통 코드를 볼 때마다 추상 클래스를 사용했습니다.
• 인터페이스와 추상 클래스를 작성하여 클래스를 분리 테스트 할 수있었습니다. 실수로 모의 객체를 작성하게합니다. (인터페이스 분리 원리)
• 많은 인터페이스와 추상 클래스를 작성했기 때문에 공통 유형을 사용하도록 변수와 매개 변수를 선언하기 시작했습니다 (종속 반전 원리).

항상 테스트를 먼저 수행하지는 않지만 테스트를 좀 더 쉽게하기 위해 따라야 할 좋은 OO 원칙과 관행을 따릅니다. 이제는 자체 코드를 작성하지 않습니다. 쉽게 테스트하거나 더 중요하게 코드를 작성했습니다. 쉽게 유지 .

다른 모든 대답은 훌륭하지만 만지지 않은 한 가지 점이 있습니다. 테스트를 먼저 작성하면 테스트가 작성됩니다. 일단 작업 코드를 작성하면 테스트를 건너 뛰고 UI를 통해 테스트하려는 유혹이 있습니다. 코드를 작성하기 전에 항상 테스트에 실패한 규칙이 있으면이 트랩을 피할 수 있습니다.

테스트를 먼저 작성하면 디자인이 "돌로 캐스트"되기 전에 디자인에 대해 생각할 수있는 또 다른 기회가됩니다.

예를 들어, 특정 매개 변수 세트를 취하는 메소드가 필요하다고 생각할 수 있습니다. 그리고 코드를 먼저 작성한 경우 해당 방식으로 코드를 작성하고 테스트를 지정된 매개 변수에 맞 춥니 다. 그러나 테스트를 먼저 작성하는 경우 "잠시만 기다리십시오.이 매개 변수를 기본 코드에 사용하고 싶지 않으므로 API를 변경해야합니다."라고 생각할 수 있습니다.

테스트 작성을 시작한 다음 코딩으로 넘어 가기위한 많은 권장 사항을 볼 때,

이것에 대한 진정한 이유가 있습니다.

"옳은 기분으로 행동하라"라고 말하면 사람들은 가장 멍청하고 끔찍한 일을합니다.

"테스트를 먼저 작성하십시오"라고 말하면 사람들이 적어도 올바른 일을 시도 할 수 있습니다.

다른 방법으로 코드를 작성한 다음 단위 테스트를 수행하면 단점은 무엇입니까?

일반적으로 시끄러운 테스트 및 테스트 가능하도록 재 작업해야하는 디자인.

그러나 이것은 "보통"일뿐입니다. 어떤 사람들은 디자인과 테스트를 동시에 발전시킵니다. 어떤 사람들은 테스트 가능한 코드를 작성하고 재 작업없이 테스트를 작성합니다.

"테스트 우선"규칙은 실마리가 전혀없는 사람들을 가르치고 가르치기 위해 특별히 있습니다.

비슷한 방식으로 길을 건너기 전에 항상 "두 가지 방법"을 보라고합니다. 그러나 실제로는 그렇지 않습니다. 그리고 그것은 중요하지 않습니다. 나는 오른 손잡이 운 전국에 살고 있으며, 건너기 시작할 때 왼쪽 만 봐야합니다.

왼손잡이 국가를 방문했을 때, 왼쪽 만 보면 나를 죽일 수있었습니다.

규칙은 이유를 위해 매우 강력하게 명시되어 있습니다.

당신이하는 일은 당신 자신의 문제입니다.

시험을 작성하는 요점은

• 코드를 테스트하는 방법
• 테스트 할 수 있도록 코드가 있어야하는 인터페이스

간단한 일을한다면, 테스트가 간단하고 인터페이스가 분명하기 때문에 어떤 것을 먼저 작성하든 (테스트 우선 습관을 기르는 것이 좋지만) 중요하지 않을 것입니다

그러나 TDD는 단위 테스트뿐만 아니라 승인 테스트로 확장되며 인터페이스가 중요하지 않습니다.

먼저 테스트를 작성하지 않으면 TDD (Test Driven Development)를 수행하지 않는 것입니다. 이점은 다양하며 여러 번 연습 할 때까지 종종 믿기 어렵습니다. 기존 개발에 비해 TDD를 통해 얻은 이점은 다음과 같습니다.

1. 테스트의 안전망-무의식적으로 무언가를 깰 염려없이 큰 변화를 만들 수 있습니다
2. 유기적 인 디자인-내가 끝내는 디자인은 일반적으로 처음부터 끝났을 때의 디자인과 항상 다르며 항상 더 좋았습니다.
3. 생산성-작은 목표를 향해 노력하고 (이 하나의 테스트를 통과) 모든 테스트를 통과하면 실제로 효과가 있으며 동기를 부여합니다. 한 쌍으로 추가하면 생산성이 새로운 최고 수준에 도달합니다.

책 : Beck, K. 예제를 통한 테스트 주도 개발

좋은 예 : http://jamesshore.com/Blog/Lets-Play/

테스트를 작성할 때 실패 조건을 감지하는 방법을 어떻게 알 수 있습니까? 답은 "테스트 테스트"입니다. 그렇게하는 방법은 먼저 테스트를 작성하고 실패한 것을보고 테스트중인 장치가 성공적으로 코딩되었을 때만 통과하는 것을 보는 것입니다 (다른 답변 중 하나에 언급 된 빨간색 / 녹색 / 리 팩터 사이클).

먼저 코드를 작성하고 테스트를 수행하면 테스트에 정직한 실패가 있는지 여부에 대한 의문이 남습니다.

테스트는 사양을 나타냅니다. 코드가 "모양"될 때 ​​테스트를 수정해야하는 경우 사양이 변경되고 있음을 나타냅니다. 그것은 좋을 수도 있고 아닐 수도 있습니다. 문제에 대한 이해가 처음에는 정확하지 않았 음을 의미 할 수 있습니다. 다른 한편으로, 그것은 당신이 달성하고자 하는 것이 아니라 장치가 어떻게 일을하고 있는지 "테스트하는"것을 의미 할 수 있습니다.