TDD에서 언제 "진짜"코드를 작성합니까?

johnny 08/19/2017. 11 answers, 20.464 views
tdd

내가 읽은 동영상을 보면서 보았던 모든 예는 단순한 예를 가지고 있습니다. 하지만 내가 그린이 된 후 "실제"코드를 어떻게 작성하는지는 알 수 없습니다. 이것이 "리 팩터"부분입니까?

복잡한 방법으로 상당히 복잡한 오브젝트가 있고, 테스트를 통과하고 최소한의 테스트 만 통과하면 (처음 실패한 후에는 빨간색으로 표시). 언제 다시 돌아가 실제 코드를 작성합니까? 그리고 다시 테스트하기 전에 얼마나 많은 실제 코드를 작성합니까? 나는 마지막 하나가 더 직관이라고 생각합니다.

Edit: 응답 모든 사람에게 감사드립니다. 귀하의 모든 답변은 저에게 큰 도움이되었습니다. 내가 묻거나 혼란스러워하는 것에 대해 다른 생각이있는 것 같습니다. 어쩌면 그럴 수도 있습니다. 그러나 제가 묻는 것은 제가 학교를 세우는 신청서를 가지고 있다고 말하고있는 것입니다.

필자의 설계에서는 필자가 시작하고자하는 아키텍처, User Stories 등이있다. 여기에서 사용자 스토리를 가져와 사용자 스토리를 테스트하는 테스트를 만듭니다. 사용자는 학교에 등록하고 등록비를 지불해야합니다. 그래서, 나는 그것을 실패하게 만드는 방법을 생각합니다. 그렇게함으로써 나는 클래스 X (어쩌면 학생)에 대한 테스트 클래스를 디자인하는데, 이것은 실패 할 것이다. 그런 다음 클래스 "학생"을 만듭니다. 어쩌면 "학교"나도 몰라.

그러나, 어떤 경우 에든, TD Design 은 내가 이야기를 통해 생각하도록 강요하고 있습니다. 내가 시험을 실패하게 만들 수 있다면, 나는 그것이 실패한 이유를 안다.하지만 이것은 전제 조건이 될 수있다. 그것은 디자인에 관한 것입니다.

나는 이것을 재귀에 대해 생각하는 것과 비유한다. 재귀는 어려운 개념이 아닙니다. 머리 속에서 실제로 그것을 추적하는 것이 더 힘들지 만, 실제로, 가장 어려운 부분은 재귀가 "끊어 질 때"언제 멈출 지 (내 의견은 물론입니다.) 그래서 무엇이 멈추는 지 생각해야합니다 재귀가 먼저. 이것은 단지 불완전한 유추 일 뿐이며, 각 재귀 반복은 "통과"라고 가정합니다. 다시 한 번 의견.

구현시 학교는보기가 어렵습니다. 숫자 및 은행 원장은 간단한 산술을 사용할 수 있다는 의미에서 "쉽다". 나는 + b를보고 0을 반환 할 수 있습니다. 사람들의 시스템의 경우, 그것을 implement 하는 방법을 더 열심히 생각 implement 합니다. 나는 실패, 통과, 리팩토링의 개념을 가지고있다. (주로 연구와이 질문 때문이다.)

내가 모르는 것은 제 경험으로는 부족하다는 것입니다. 나는 새로운 학생을 등록하는 것을 실패하는 방법을 모른다. 성을 입력하고 데이터베이스에 저장하는 방법에 실패하는 방법을 모르겠습니다. 나는 간단한 수학을 위해 + 1을 만드는 방법을 알고 있지만, 사람과 같은 엔티티를 사용하면 누군가가 데이터베이스에 고유 이름을 입력 할 때 데이터베이스 고유 ID 또는 다른 것을 얻는 지 테스트하려고하는지 알지 못합니다. 데이터베이스 또는 둘 다 또는 둘 다.

또는 어쩌면 이것은 여전히 ​​혼란 스럽다는 것을 보여줍니다.

5 Comments
187 hobbs 07/25/2017
TDD 사람들이 밤에 집에 간 후에.
14 Goyo 07/25/2017
왜 쓴 코드가 진짜가 아니라고 생각하니?
2 johnny 07/26/2017
@RubberDuck 다른 답변보다. 나는 그것을 곧 참조 할 것이라고 확신한다. 그것은 여전히 ​​외국의 일종이지만, 나는 그것을 포기하지 않을 것입니다. 네가 한 말이 말이야. 내 컨텍스트 또는 일반 비즈니스 응용 프로그램에서 의미가 있도록하려는 것입니다. 어쩌면 재고 시스템 등일 수도 있습니다. 나는 그것을 고려해야 만한다. 나는 당신의 시간 동안 감사합니다. 감사.
1 Edmund Reed 07/26/2017
대답은 이미 머리에 맞았지만, 모든 테스트가 끝나고 새로운 테스트 / 기능이 필요하지 않은 한, 코드 완성, 바 linting이 있다고 가정 할 수 있습니다.
3 Borjab 07/26/2017
"복잡한 방법으로 상당히 복잡한 대상이 있습니다"라는 질문에 문제가있을 수 있습니다. TDD에서는 테스트를 먼저 작성하므로 매우 간단한 코드로 시작합니다. 이렇게하면 모듈 식이어야하는 테스트 친화적 인 구조를 코딩 할 수 있습니다. 복잡한 동작은보다 단순한 객체를 결합하여 만들어집니다. 상당히 복잡한 객체 나 메소드로 끝내면 리팩터링 할 때입니다.

11 Answers


RubberDuck 07/27/2017.

복잡한 방법으로 상당히 복잡한 오브젝트가 있고, 테스트를 통과하고 최소한의 테스트 만 통과하면 (처음 실패한 후에는 빨간색으로 표시). 언제 다시 돌아가 실제 코드를 작성합니까? 그리고 다시 테스트하기 전에 얼마나 많은 실제 코드를 작성합니까? 나는 마지막 하나가 더 직관이라고 생각합니다.

당신은 "돌아가서" "진짜 코드"를 쓰지 않습니다. 그것은 모두 진짜 코드입니다. 당신이해야 할 일은 돌아가서 새로운 테스트를 통과하기 위해 코드를 change 하도록하는 또 다른 테스트를 추가하는 것입니다.

다시 테스트하기 전에 얼마나 많은 코드를 작성합니까? 없음. 더 많은 코드를 작성해야하는 실패 테스트없이 zero 코드를 작성합니다.

패턴을 주목 해?

도움이되기를 희망하면서 (다른) 간단한 예제를 살펴 봅시다.

 Assert.Equal("1", FizzBuzz(1)); 

쉬운 peazy.

 public String FizzBuzz(int n) {
    return 1.ToString();
} 

실제 코드라고 부르는 것이 아닙니다. 맞습니까? 변경을 강제하는 테스트를 추가합시다.

 Assert.Equal("2", FizzBuzz(2)); 

if n == 1 처럼 바보 같이 할 수도 있지만 정상적인 해결책으로 건너 뛸 것입니다.

 public String FizzBuzz(int n) {
    return n.ToString();
} 

시원한. 이것은 FizzBuzz가 아닌 모든 번호에서 작동합니다. 생산 코드를 변경하게 할 다음 입력은 무엇입니까?

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
} 

그리고 다시. 아직 통과하지 못할 테스트를 작성하십시오.

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
} 

이제 우리는 3의 모든 배수를 다룹니다 (5의 배수가 아니기 때문에이를 메모하고 다시 돌아옵니다).

"Buzz"에 대한 테스트를 아직 작성하지 않았으므로 작성하십시오.

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
} 

그리고 다시, 우리는 우리가 처리해야 할 또 다른 경우가 있음을 압니다.

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
} 

이제 우리는 3의 배수가 아닌 5의 모든 배수를 처리 할 수 ​​있습니다.

이 시점까지는 리팩토링 단계를 무시했지만 일부 복제본을 보았습니다. 이제 그걸 정리하자.

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

시원한. 이제 복제본을 제거하고 잘 명명 된 함수를 만들었습니다. 코드를 변경하도록 우리가 작성할 수있는 다음 테스트는 무엇입니까? 음, 우리는 숫자가 3과 5로 나눌 수있는 경우를 피했습니다. 지금 작성해 봅시다.

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

테스트는 통과하지만 더 많은 중복이 있습니다. 우리는 옵션을 가지고 있지만 "로컬 변수 추출"을 몇 번 적용하여 재 작성하는 대신 리팩토링을 할 것입니다.

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

그리고 합리적인 모든 입력을 다루었지만 unreasonable 입력은 무엇입니까? 0 또는 음수를 전달하면 어떻게됩니까? 테스트 케이스를 작성하십시오.

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

"실제 코드"처럼 보이기 시작 했습니까? 무엇보다 중요한 점은 "언리얼 코드"가 중단되고 "진짜"로 전환하는 시점이 무엇 이었습니까? 그것은 숙고 할 것이 있습니다 ...

그래서, 나는 각 단계에서 통과하지 못할 것이라는 것을 알고있는 테스트를 찾음으로써 이것을 간단하게 수행 할 수 있었지만 많은 연습을했습니다. 내가 일하고있을 때 상황이 이렇게 간단하지 않고 어떤 테스트가 변화를 일으키는 지 항상 알지 못할 수도 있습니다. 때로는 시험을 치고 이미 통과 한 것을보고 놀라게 될 것입니다! 시작하기 전에 "테스트 목록"을 만드는 습관을 갖기를 강력히 권장합니다. 이 테스트 목록에는 생각할 수있는 모든 "흥미로운"입력이 포함되어야합니다. 이 모든 것을 사용하지 않을 수도 있고, 가면서 케이스를 추가 할 수도 있지만이 목록은 로드맵의 역할을합니다. FizzBuzz에 대한 테스트 목록은 다음과 같습니다.

  • 부정
  • 제로
  • 하나
  • 다섯
  • 6 개 (3의 배수가 아닌)
  • 나인 (3 제곱)
  • 10 (5의 사소하지 않은 배수)
  • 15 (3 및 5의 배수)
  • 30 (3 & 5 중 사소하지 않음)
5 comments
3 maple_shaft♦ 07/27/2017
코멘트는 확장 토론이 아닙니다. 이 대화는 채팅 으로 이동 되었습니다.
40 GManNickG 07/27/2017
이 답변을 완전히 오해하지 않는 한 : "n == 1처럼 바보 같이 할 수는 있지만 정상적인 해결책으로 건너 뛸 것입니다." - 모든게 바보 같았 어. 앞부분에서 <spec>을 수행하는 함수를 원한다면 <spec>에 대한 테스트를 작성하고 분명히 <spec>에 실패한 버전을 작성하는 부분은 건너 뜁니다. <spec>에 버그를 발견했다면, 먼저 수정을하기 전에 테스트를 수행하고 수정 후에 테스트가 통과하는지 확인하는 테스트를 작성하십시오. 그러나 이러한 모든 중간 단계를 위조 할 필요는 없습니다.
15 user3791372 07/28/2017
이 답변과 TDD의 주요 결함을 설명하는 주석은 일반적으로 채팅으로 이동되었습니다. TDD 사용을 고려하고 있다면 '채팅'을 읽어보십시오. 불행히도 '품질'의견은 미래의 학생들이 읽을 수있는 채팅로드에 숨겨져 있습니다.
nbro 07/28/2017
이 답변을 개선하고 싶다면이 "테스트 목록"의 내용에 관해서는 더 정확할 것입니다. 명시 적으로 "경계 값"과 "클래스 분할"에 대해 이야기 할 것입니다.
2 hvd 07/30/2017
@ GManNickG 나는 그 요점이 올바른 양의 테스트를 얻는 것이라고 믿는다. 테스트를 미리 작성하면 특별한 경우를 테스트해야하는 것을 놓치기 쉬우므로 테스트에서 적절하게 다루어지지 않는 상황이나 테스트에서 무의미하게 다뤄지는 동일한 상황에 이르게 할 수 있습니다. 이러한 중간 단계가 없으면 그렇게 할 수 있습니다. 모두가 그렇게 할 수있는 것은 아니지만 실천을 필요로합니다.

GenericJon 07/24/2017.

"실제"코드는 테스트를 통과하기 위해 작성한 코드입니다. Really . 그것은 간단합니다.

사람들이 테스트를 녹색으로 만들기 위해 최소값을 쓰는 것에 대해 이야기 할 때, 이는 실제 코드가 YAGNI 원칙을 따라야 함을 의미합니다.

리팩토러 단계의 아이디어는 요구 사항을 만족하는 것이 행복해지면 작성한 내용을 정리하는 것입니다.

작성한 테스트가 제품 요구 사항을 실제로 포함하는 한, 코드가 완료되면 코드가 완료됩니다. 모든 비즈니스 요구 사항에 테스트가 있고 모든 테스트가 녹색이라면 무엇을 쓸 것인가? (실제 생활에서는 완전한 테스트 커버리지가없는 경향이 있지만 이론은 건전합니다.)

5 comments
44 Derek Elkins 07/24/2017
단위 테스트는 비교적 사소한 요구 사항에 대한 제품 요구 사항을 실제로 포괄 할 수 없습니다. 기껏해야, 그것들은 입출력 공간을 샘플링하는데, 당신이 (정확하게) 완전한 입출력 공간으로 일반화한다는 아이디어가 있습니다. 물론, 코드는 모든 테스트에 합격하고 다른 입력에 실패하는 각 단위 테스트의 경우가 큰 switch 일 수 있습니다.
8 Taemyr 07/25/2017
@DerekElkins TDD는 실패한 테스트를 요구합니다. 단위 테스트에 실패하지 않았습니다.
6 jonrsharpe 07/25/2017
@DerekElkins는 단위 테스트를 작성하는 것이 아니라 왜 가짜가 아닌 무언가를 만들려고한다는 일반적인 가정이있는 이유입니다!
35 Derek Elkins 07/25/2017
@ 논리, 나는 결코 사소한 구현을 쓰지 않을 것이다. 예를 들어 RubberDuck의 답변 (단 단위 테스트 만 사용하는)의 FizzBuzz 예제에서 첫 번째 구현은 "그냥 가짜"입니다. 질문에 대한 나의 이해는 당신이 알고있는 불완전한 코드와 진정으로 요구 사항 인 "실제 코드"를 구현할 것이라고 믿는 코드 사이의 이분법입니다. 내 "큰 switch "는 "테스트를 녹색으로 만들기 위해 최소값을 쓰는 것"의 논리적 극단적 인 의도였습니다. 나는 OP의 질문을 다음과 같이 생각한다 : TDD에서이 큰 switch 을 피하는 원칙은 어디에 있는가?
2 Luaan 07/25/2017
@GenericJon 그건 내 경험으로는 너무 낙관적이다. :) 하나는 생각이없는 반복적 인 작업을 즐기는 사람들이다. 그들은 "복잡한 의사 결정"보다는 거대한 전환 발표문으로 더 행복 할 것입니다. 그리고 일자리를 잃기 위해 기술에 대해 부르는 사람이 필요합니다 (실제로 회사의 기회 / 돈을 잃어 버리는 좋은 증거가 더 있습니다!). 그러한 많은 프로젝트의 유지 관리를 맡은 후에 나는 고객이 행복하고 (그리고 지불하는) 매우 순진한 코드가 수십 년 동안 지속되기 쉽다는 것을 알 수 있습니다.

Carl Raymond 07/24/2017.

간단히 대답하면 "실제 코드"는 테스트를 통과시키는 코드입니다. 실제 코드가 아닌 다른 것으로 테스트를 통과 할 수 있다면 더 많은 테스트를 추가하십시오!

나는 TDD에 관한 많은 튜토리얼이 단순하다는 것에 동의한다. 그건 그 사람들을 상대로 일합니다. 말하자면, 3 + 8을 계산하는 방법에 대한 너무 간단한 테스트는 실제로 3 + 8을 계산하고 그 결과를 비교하는 것 외에는 선택의 여지가 없습니다. 따라서 코드를 모두 복제하는 것처럼 보이게하고 테스트는 무의미하고 오류가 발생하기 쉬운 작업입니다.

테스트가 잘되면 응용 프로그램을 구조화하는 방법과 코드를 작성하는 방법을 알려줍니다. 합리적이고 도움이되는 테스트를 수행하는 데 어려움이있는 경우 디자인을 다시 생각해야합니다. 잘 설계된 시스템은 테스트하기 쉽습니다. 합리적인 테스트는 생각하기 쉽고 구현하기 쉽습니다.

테스트를 먼저 작성하고 실패한 것을 확인한 다음 통과시키는 코드를 작성하면 모든 코드가 해당 테스트를 갖도록하는 규율이됩니다. 나는 내가 코딩 할 때 그 규칙을 철저히 따르지 않는다. 종종 나는 사실 이후에 시험을 쓴다. 그러나 먼저 테스트를하면 정직하게 유지하는 데 도움이됩니다. 몇 가지 경험을 통해 테스트를 처음 작성하지 않아도 코딩 할 때 알아 차리기 시작할 것입니다.

4 comments
6 Steve Jessop 07/26/2017
개인적으로, assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) 아닌 assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) 합니다. 보다 복잡한 경우에는 항상 테스트에서 올바른 결과를 동적으로 계산하고 평등을 확인하는 other than 올바른 결과를 증명하는 방법을 찾으십시오.
Steve Jessop 07/26/2017
그래서이 예제를 위해 정말 바보 같은 방법을 사용하면 plus(3,8) 가 3을 빼고 8을 빼고 결과를 0으로 확인하여 올바른 결과가 반환되었음을 증명할 수 있습니다. 이것은 매우 분명합니다. assertEqual(plus(3,8), 3+8) 과 동등하지만, 테스트중인 코드가 단순한 정수보다 복잡한 것을 만들고 있다면 결과를 얻고 각 부분의 정확성을 검사하는 것은 종종 올바른 접근법. 또는 for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
왜냐하면 테스트를 작성할 때 실제 코드에서 작성한 "10을 추가하는 방법"이라는 주제에 대해 동일한 실수를 저지르는 큰 두려움을 피할 수 있습니다. 따라서 테스트는 신중하게 10을 추가하는 코드를 작성하지 않으며 plus() 가 10을 추가 할 수 있다는 테스트에서 제외됩니다. 물론 우리는 여전히 프로그래머가 검증 한 초기 루프 값에 의존합니다.
3 Warbo 07/28/2017
사실을 테스트 한 후에도 테스트를 작성한다고해도, 실패한 것을 지켜 보는 것은 여전히 ​​좋은 생각입니다. 당신이하고있는 일에 무엇이든 중요하게 보이는 코드의 일부를 찾으십시오. 약간 수정하십시오 (예 : +를 - 등으로 바꾸기). 테스트를 실행하고 실패한 것을 지켜보고, 변경 사항을 취소하고 통과를 지켜보십시오. 이 테스트를 실제로 여러 번 반복하면 테스트가 실제로 실패하지 않으므로 쓸데없는 것보다 더 나빠집니다. 테스트하지 않을뿐만 아니라 테스트가 진행되고 있다는 잘못된 인식을 갖게됩니다!

Victor Cejudo 07/25/2017.

때때로 TDD에 대한 몇 가지 예는 오도 할 수 있습니다. 이전에 다른 사람들이 지적했듯이 테스트를 통과하기 위해 작성한 코드가 실제 코드입니다.

그러나 실제 코드가 마술처럼 보일 것이라고 생각하지 마십시오. 잘못된 것입니다. 당신은 당신이 원하는 것을 더 잘 이해할 필요가 있으며, 가장 쉬운 케이스와 코너 케이스부터 테스트를 선택해야합니다.

예를 들어, 렉서 (lexer)를 작성해야하는 경우에는 빈 문자열로 시작한 다음 일련의 공백 문자로 시작한 다음 숫자와 공백 문자로 둘러싸인 숫자로 시작한 다음 잘못된 숫자로 시작합니다. 이러한 작은 변환으로 인해 올바른 알고리즘이지만, 가장 쉬운 경우에서 실제 코드를 수행하기 위해 무작위로 선택한 매우 복잡한 경우로 이동하지 마십시오.

Bob Martin은 완벽하게 설명합니다.


CandiedOrange 07/25/2017.

리팩토링 부분은 피곤할 때 정리되고 집에 가고 싶습니다.

피쳐를 추가하려고 할 때 리팩토링 부분은 다음 테스트 전에 변경하는 부분입니다. 새 기능을위한 공간을 만들기 위해 코드를 리팩토링합니다. 새로운 기능이 무엇인지 know 때이 작업을 수행하십시오. 당신이 상상할 때가 아닙니다.

테스트를 추가 한 후 GreetMom 클래스를 만들어 "Hi Mom"을 인쇄 할 기능을 추가하기 전에 GreetImplGreetWorld 로 이름을 바꾸는 GreetImpl 큼 간단 할 수 있습니다.


graeme 07/27/2017.

그러나 실제 코드는 TDD 단계의 리팩토링 단계에 나타납니다. 즉, 최종 릴리스에 포함되어야하는 코드입니다.

테스트는 변경 될 때마다 실행되어야합니다.

TDD 수명주기의 모토는 다음과 같습니다. RED GREEN REFACTOR

RED : 시험 쓰기

GREEN : 가능한 한 빨리 테스트를 통과하는 기능 코드를 얻으려는 정직한 시도를하십시오 : 중복 된 코드, 모호한 이름의 변수가 가장 높은 순서의 해킹 등.

REFACTOR : 코드를 정리하고 변수 이름을 올바르게 지정하십시오. 코드를 말라 .

5 comments
5 mcottle 07/25/2017
나는 당신이 "그린"단계에 대해 무엇을 말하고 있는지 알고 있지만 테스트 통과를위한 하드 와이어 리턴 값이 적절할 수도 있음을 의미합니다. 내 경험에 따르면 "Green"은 요구 사항을 충족하기 위해 작업 코드를 작성하려는 정직한 시도 여야합니다. 완벽하지는 않지만 개발자가 첫 번째 단계에서 관리 할 수있는 "배송 가능"상태 여야합니다. 리팩토링은 아마도 개발이 끝나고 나서 첫 번째 단계에서의 문제가 드러나고 DRY가 나타날 기회가 생겨서 얼마 후 가장 잘 수행 될 것입니다.
graeme 07/25/2017
@ mcottle 나는이 모든 일을 같은 일로 생각한다. 끝내고 청소하십시오. 다른 작업의 일부로 시간이 갈수록 더 많은 리팩토링이 수행되어야합니다.
1 Bryan Boettcher 07/25/2017
@mcottle : get-only 저장소의 구현이 코드베이스에서 하드 코딩 된 값이 될 수 있다는 것에 놀랄 수도 있습니다. :)
6 Kaz 07/25/2017
내가 쓰는 것만 큼 빨리, 생산 품질의 코드를 만들어 낼 수있을 때 왜 내가 쓰레기를 쓰고 청소할 수 있을까? :)
1 Kaz 07/27/2017
@TimothyTruckle 가장 단순한 가능한 변경을 찾기 위해 50 분이 걸리지 만 두 번째로 간단한 가능한 변경을 찾기 위해 5 분이 소요됩니까? 우리는 두 번째로 간단하게 가거나 가장 단순한 것을 계속 찾고 있습니까?

Timothy Truckle 07/27/2017.

TDD에서 언제 "진짜"코드를 작성합니까?

red 단계는 코드를 write 곳입니다.

refactoring 단계에서 주요 목표는 코드를 delete 것입니다.

red 단계에서는 as quick as possible 테스트를 통과 할 수있는 모든 작업을 수행 at any cost . 좋은 코딩 방법이나 디자인 패턴에 대해 들어 본 적이없는 것을 완전히 무시합니다. 테스트를 녹색으로 만드는 것이 중요합니다.

refactoring 단계에서 방금 만든 엉망을 정리합니다. 이제 막 변경 한 내용이 변형 우선 순위 목록 의 맨 위에있는 종류인지 확인하고 코드 중복이있는 경우 디자인 패턴을 적용하여 가능성이 가장 큰 항목을 제거 할 수 있습니다.

마침내 식별자의 이름을 변경하고 magic numbers 및 / 또는 리터럴 문자열을 상수로 추출하여 가독성을 향상시킵니다.


그것은 레드 리팩토링이 아니며, 레드 그린 리팩토링입니다. - Rob Kinyon

이걸 알려줘서 고마워.

real code 를 작성하는 것은 green 단계입니다.

red 단계에서는 executable specification 을 작성합니다 ...

2 comments
Rob Kinyon 07/27/2017
그것은 레드 리팩토링이 아니며, 레드 그린 리팩토링입니다. "빨간색"은 테스트 스위트를 녹색 (모든 테스트 통과)에서 빨간색 (한 테스트 실패)으로 가져가는 것입니다. "초록색"은 빨간색 (한 테스트 실패)에서 녹색 (모든 테스트 통과)까지 실수로 테스트 스위트를 가져가는 곳입니다. "리팩터링"은 코드를 가져 와서 모든 테스트를 통과시킨 채로 예쁜 코드를 만드는 곳입니다.
Timothy Truckle 07/27/2017
@ RobKinyon 감사합니다, 답변을 업데이 트되었습니다.

Robert Andrzejuk 07/27/2017.

당신은 전체 시간 동안 Real Code 작성하고 있습니다.

각 단계에서 귀하는 향후 귀하의 코드 발신자 (귀하 또는하지 않을 수 있음)를 위해 귀하의 코드가 만족할 수있는 조건을 충족시키기위한 코드를 작성하고 있습니다.

당신은 유용한 ( real ) 코드를 작성하지 않는다고 생각합니다. 잠시 후에 당신은 그것을 리팩토링 할 수 있습니다.

코드 리팩토링 은 외부 행동을 변경하지 않고 기존 컴퓨터 코드를 재구성하여 팩토링을 변경하는 프로세스입니다.

즉, 코드를 변경하더라도 코드가 만족하는 조건은 변경되지 않습니다. 그리고 코드가 이미 수정되었는지 확인하기 위해 구현 한 검사 ( tests )를 통해 수정 내용이 변경되었는지 확인합니다. 그래서 당신이 작성한 코드는 다른 방식으로 거기에 있습니다.

실제 코드가 아니라고 생각할 수있는 또 다른 이유는 최종 프로그램이 이미 사용자에 의해 예견 될 수있는 예제를 수행하고 있다는 것입니다. 이것은 당신이 프로그래밍하고있는 domain 대한 지식을 가지고 있다는 것을 보여주기 때문에 매우 좋습니다.
그러나 프로그래머는 new 것이고 unknown domain 있는 경우가 많습니다. 그들은 최종 결과가 무엇인지 알지 못합니다. TDD는이 시스템이 어떻게 작동해야하는지에 대한 knowledge 문서화하고 코드가 그런 식으로 작동 하는지를 검증함으로써 프로그램을 단계적으로 작성하는 technique 입니다.

TDD에서 The Book (*)을 읽었을 때 가장 중요한 기능은 TODO 목록이었습니다. TDD는 개발자가 한 번에 한 가지만 집중할 수 있도록 도와주는 기술이기도합니다. 그래서 이것은 또한 귀하의 질문에 대한 답변입니다. How much Real code to write 합니까? 나는 한 번에 한 가지만 집중할 수있는 충분한 코드를 말할 것입니다.

(*) "테스트 주도 개발 : 예"by Kent Beck

1 comments
2 Robert Andrzejuk 07/27/2017
"테스트 주도 개발 : 예"by Kent Beck

Zenilogix 07/31/2017.

테스트를 실패하게 만드는 코드를 작성하지 않았습니다.

테스트를 작성하여 성공의 모양을 정의하십시오. 아직 통과 할 코드를 작성하지 않았으므로 처음에는 모두 실패해야합니다.

초기에 실패한 테스트 작성에 관한 요점은 두 가지를하는 것입니다.

  1. 모든 케이스 커버 - 모든 명목 케이스, 모든 에지 케이스 등
  2. 테스트의 유효성을 검사하십시오. 그 (것)들이 다만 통과하는 볼 경우, 어떻게 에이스가 발생할 때 확실하게 실패를보고 할 것이라는 점을 당신은 확실 할 수 있는가?

적색 - 녹색 - 리팩터링의 핵심은 정확한 테스트를 먼저 작성하면 테스트를 통과하기 위해 작성한 코드가 정확하다는 것을 알 수 있고 자신의 테스트가 곧바로 알려줄 것이라는 확신을 가지고 리팩토링 할 수 있다는 것입니다. 무언가가 깨져서 즉시 돌아가서 고칠 수 있습니다.

내 자신의 경험 (C # / .NET)에서는 아직 존재하지 않는 메서드에 대한 호출을 컴파일 할 수 없기 때문에 순수 테스트 우선을 달성 할 수없는 이상입니다. 따라서 "테스트 우선"은 인터페이스를 작성하고 구현을 먼저 스터 빙한 다음 스텁이 제대로 풀릴 때까지 스텁에 테스트를 작성하는 것입니다. 필자는 "실패한 코드"를 작성하지 않고 스텁에서 구축합니다.


Zan Lynx 07/27/2017.

나는 당신이 단위 테스트와 통합 테스트 사이에 혼란 스러울 수도 있다고 생각합니다. 수락 테스트도있을 수 있지만 귀하의 프로세스에 따라 다릅니다.

작은 "단위"를 모두 테스트했으면 모두 조립 또는 "통합"되었는지 테스트합니다. 그것은 보통 전체 프로그램이나 라이브러리입니다.

필자가 작성한 코드에서는 데이터를 읽고이를 라이브러리에 공급하는 다양한 테스트 프로그램이있는 라이브러리를 테스트 한 다음 결과를 확인합니다. 그런 다음 스레드로 처리합니다. 그런 다음 중간에 스레드와 fork ()를 사용하여 작업을 수행합니다. 그런 다음 2 초 후 -9를 실행 한 다음 시작하여 복구 모드를 확인합니다. 나는 그것을 모릅니다. 나는 모든 종류의 방법으로 그것을 고문한다.

모두 테스트 중이지만, 결과에 대해서는 꽤 빨간색 / 녹색 디스플레이가 없습니다. 그것은 성공하거나, 왜 수천 줄의 오류 코드를 파고 그 이유를 찾아냅니다.

이것이 바로 "실제 코드"를 테스트하는 곳입니다.

그리고 저는 이것에 대해서 생각해 봤지만 어쩌면 당신이 단위 테스트를 할 때 언제쯤인지 알 수 없을 것입니다. 테스트에서 지정한 모든 작업을 수행하면 단위 테스트를 작성합니다. 때로는 모든 오류 처리 및 엣지 사례 중에서 그 문제를 추적 할 수 있기 때문에 간단히 사양을 통과하는 행복한 경로 테스트의 멋진 테스트 그룹을 만들고 싶을 수도 있습니다.

1 comments
Peter Mortensen 07/27/2017
(= 소유욕, 그것은 "있다"또는 "가지고있다". 예를 들면 How to Use Its and It's 보십시오.)

user3791372 07/27/2017.

문제의 제목에 대한 대답 : "TDD에서"진짜 "코드를 작성할 때"대답은 '거의 없습니다'또는 '매우 느리게'입니다.

당신은 학생처럼 들리므로 학생에게 조언하는 것처럼 대답 할 것입니다.

당신은 많은 '이론'과 '기법'을 배우게 될 것입니다. 비싼 가격의 학생 강좌에 시간을 할애 할 수는 있지만, 절반의 시간 동안 책을 읽을 수 없다는 이점은 거의 없습니다.

코더의 역할은 전적으로 코드를 생성하는 것입니다. 정말 잘 작동하는 코드. 이것이 코더가 당신의 마음 속에, 종이에, 적절한 애플리케이션으로 코드를 계획하는 이유이며 코딩하기 전에 논리적으로나 옆으로 생각함으로써 가능한 결함 / 구멍을 사전에 해결할 계획입니다.

그러나 적절한 코드를 설계 할 수 있도록 응용 프로그램을 중단하는 방법을 알아야합니다. 예를 들어 Little Bobby Table (xkcd 327)에 대해 알지 못했다면 데이터베이스로 작업하기 전에 입력 내용을 살균하지 않을 것입니다. 따라서 해당 개념을 중심으로 데이터를 보호 할 수는 없습니다.

TDD는 응용 프로그램을 코딩하기 전에 잘못 될 수있는 것의 테스트를 작성하여 코드의 버그를 최소화하도록 설계된 워크 플로입니다. 코드를 더 많이 소개할수록 코드가 기하 급수적으로 어려워졌으며 이전에 생각한 버그를 잊어 버릴 수 있습니다. 일단 응용 프로그램을 끝냈다 고 생각하면 테스트를 실행하고 호기심을 자극하여 테스트에 버그가 생길 것입니다.

TDD는 - 일부 사람들이 믿는 것처럼 - 테스트를 작성하고, 최소한의 코드로 전달하고, 다른 테스트를 작성하고, 최소한의 코드로 전달하는 등의 방법은 아닙니다. 대신 코드 작성을 도와주는 방법입니다. 테스트와 함께 작동하도록 코드를 리팩토링하는 이상적인 아이디어는 바보 같지만, 새로운 기능을 추가 할 때 느낌이 좋고 코드 작성 방법을 배우는 중이므로 학생들 사이에 좋은 개념입니다 ...

이 함정에 빠지지 말고 코드 작성의 역할을 확인하십시오. 코더의 역할은 전적으로 코드를 생성하는 것입니다. 정말 잘 작동하는 코드. 이제 전문 코더로서의 시간을 보게 될 것입니다. 클라이언트가 100,000 개의 어설 션 또는 0을 작성했는지 상관하지 않을 것입니다. 단지 작동하는 코드 만 원할뿐입니다. 사실, 사실.

5 comments
3 johnny 07/25/2017
나는 학생과 가깝지 않지만, 좋은 기술을 적용하고 전문적으로 공부하려고 노력합니다. 그래서 그 의미에서 저는 "학생"입니다. 나는 그것이 기본적인 방식이기 때문에 아주 기본적인 질문을합니다. 나는 내가하고있는 일을 왜하는지 정확히 알고 싶다. 문제의 핵심. 내가 그것을 얻지 못한다면 나는 그것을 좋아하지 않고 질문을하기 시작할 것입니다. 왜 내가 그것을 사용하려고하는지 알 필요가있다. TDD는 어떤 방식 으로든 직관적으로 훌륭하게 보이는 것처럼 보이지만, 구현을 이해하는 것은 어려웠습니다. 나는 지금 더 나은 이해를 가지고 있다고 생각한다.
4 Sean Burton 07/27/2017
그것들은 TDD의 규칙입니다. 원하는 경우 코드를 자유롭게 작성할 수 있지만 세 가지 규칙을 따르지 않으면 TDD를 수행하지 않습니다.
2 user3791372 07/27/2017
한 사람의 "규칙"? TDD는 종교가 아니라 코드 작성을 돕기위한 제안입니다. 너무 많은 사람들이 아이디어를 고수한다는 것을 슬프게 생각합니다. TDD의 기원조차도 논란의 여지가있다.
2 Alex 07/28/2017
@ user3791372 TDD는 매우 엄격하고 명확하게 정의 된 프로세스입니다. 많은 사람들이 "프로그래밍 할 때 몇 가지 테스트를해라"는 것을 의미한다고 생각한다고해도 그렇게하지는 않습니다. 여기에 용어를 섞어 보지 말자.이 질문은 일반 테스트가 아닌 프로세스 TDD에 관한 것입니다.

HighResolutionMusic.com - Download Hi-Res Songs

1 (G)I-DLE

POP/STARS flac

(G)I-DLE. 2018. Writer: Riot Music Team;Harloe.
2 Ariana Grande

​Thank U, Next flac

Ariana Grande. 2018. Writer: Crazy Mike;Scootie;Victoria Monét;Tayla Parx;TBHits;Ariana Grande.
3 Imagine Dragons

Bad Liar flac

Imagine Dragons. 2018. Writer: Jorgen Odegard;Daniel Platzman;Ben McKee;Wayne Sermon;Aja Volkman;Dan Reynolds.
4 Clean Bandit

Baby flac

Clean Bandit. 2018. Writer: Jack Patterson;Kamille;Jason Evigan;Matthew Knott;Marina;Luis Fonsi.
5 Backstreet Boys

Chances flac

Backstreet Boys. 2018.
6 BTS

Waste It On Me flac

BTS. 2018. Writer: Steve Aoki;Jeff Halavacs;Ryan Ogren;Michael Gazzo;Nate Cyphert;Sean Foreman;RM.
7 Fitz And The Tantrums

HandClap flac

Fitz And The Tantrums. 2017. Writer: Fitz And The Tantrums;Eric Frederic;Sam Hollander.
8 BlackPink

Kiss And Make Up flac

BlackPink. 2018. Writer: Soke;Kny Factory;Billboard;Chelcee Grimes;Teddy Park;Marc Vincent;Dua Lipa.
9 Lady Gaga

I'll Never Love Again flac

Lady Gaga. 2018. Writer: Benjamin Rice;Lady Gaga.
10 Diplo

Close To Me flac

Diplo. 2018. Writer: Ellie Goulding;Savan Kotecha;Peter Svensson;Ilya;Swae Lee;Diplo.
11 Halsey

Without Me flac

Halsey. 2018. Writer: Halsey;Delacey;Louis Bell;Amy Allen;Justin Timberlake;Timbaland;Scott Storch.
12 Imagine Dragons

Machine flac

Imagine Dragons. 2018. Writer: Wayne Sermon;Daniel Platzman;Dan Reynolds;Ben McKee;Alex Da Kid.
13 Little Mix

The Cure flac

Little Mix. 2018. Writer: Pete Kelleher;Camille Purcell;Tom Barnes;Ben Kohn.
14 Bradley Cooper

Always Remember Us This Way flac

Bradley Cooper. 2018. Writer: Lady Gaga;Dave Cobb.
15 Calum Scott

No Matter What flac

Calum Scott. 2018. Writer: Toby Gad;Calum Scott.
16 Frida Sundemo

Apologize flac

Frida Sundemo. 2018.
17 Little Mix

Woman Like Me flac

Little Mix. 2018. Writer: Nicki Minaj;Steve Mac;Ed Sheeran;Jess Glynne.
18 Kelly Clarkson

Never Enough flac

Kelly Clarkson. 2018. Writer: Benj Pasek;Justin Paul.
19 Ashley Tisdale

Voices In My Head flac

Ashley Tisdale. 2018. Writer: John Feldmann;Ashley Tisdale.
20 Haley Reinhart

Something Strange flac

Haley Reinhart. 2018.

Related questions

Hot questions

Language

Popular Tags