TDD와 적대적/순진한 페어링:얼마나 효과적인가요?

Question

내 친구가 직장에서 TDD와 탁구 페어링을 수행하는 방법을 설명하고 있었는데 그는 "적대적" 접근 방식을 취한다고 말했습니다.즉, 테스트 작성 담당자가 키보드를 구현자에게 넘겨줄 때 구현자는 테스트를 통과하기 위해 가장 간단한(때로는 잘못된 작업) 작업을 시도합니다.

예를 들어 GetName() 메서드를 테스트하고 테스트에서 "Sally"를 확인하는 경우 GetName 메서드의 구현은 다음과 같습니다.

public string GetName(){
    return "Sally";
}

물론 (순진하게) 테스트를 통과할 것입니다.

그는 이것이 실제 동작이나 구성 요소의 예상 상태를 테스트하는 대신 특정 미리 준비된 값을 확인하는 순진한 테스트를 제거하는 데 도움이 된다고 설명합니다.또한 더 많은 테스트를 생성하고 궁극적으로 더 나은 디자인을 만들고 버그를 줄이는 데 도움이 됩니다.

듣기에는 좋았지만 그와의 짧은 세션에서는 한 번의 테스트를 통과하는 데 다른 것보다 시간이 훨씬 오래 걸리는 것 같았고, 추가로 많은 가치를 얻었다는 느낌은 들지 않았습니다.

이 접근 방식을 사용하시나요? 그렇다면 효과가 있었나요?

Answer 1

팀의 성격에 따라 결정됩니다.모든 팀에는 구성원들의 총합인 개성이 있습니다.우월한 태도로 수동적-공격적 구현을 ​​실행하지 않도록 주의해야 합니다.일부 개발자는 다음과 같은 구현으로 인해 좌절감을 느낍니다.

return "Sally";

이러한 좌절감은 팀의 실패로 이어질 것입니다.나는 좌절감에 빠졌고 그것이 성과를 거두는 것을 보지 못했습니다.더 나은 접근 방식은 테스트를 더 잘 구현할 수 있는 방법에 대해 제안하는 구두 의사소통이 더 많다고 생각합니다.

Answer 2

매우 효과적일 수 있습니다.

다른 프로그래머가 필요한 올바른 기능을 작성하도록 하려면 어떤 테스트를 작성해야 하는지 더 많이 생각하게 됩니다.

키보드를 자주 전달하면서 코드 조각을 구성합니다.

꽤 피곤하고 시간이 많이 걸릴 수 있지만 이렇게 작성된 코드에서 다시 돌아와서 버그를 수정해야 하는 경우는 거의 없습니다.

Answer 3

나는 이 접근법을 사용했습니다.모든 쌍에서 작동하는 것은 아닙니다.어떤 사람들은 선천적으로 저항력이 있어서 정직한 기회를 주지 않습니다.그러나 이는 TDD와 XP를 올바르게 수행하는 데 도움이 됩니다.천천히 코드베이스에 기능을 추가해 보고 싶습니다.만족시키기 위해 많은 코드가 필요한 거대한 모놀리식 테스트를 작성하고 싶지는 않을 것입니다.당신은 여러 가지 간단한 테스트를 원합니다.또한 두 쌍이 모두 맞물리도록 정기적으로 쌍 사이에서 키보드를 앞뒤로 통과시키고 있는지 확인하고 싶습니다.적대적 페어링을 사용하면 두 가지를 모두 수행하게 됩니다.간단한 테스트는 간단한 구현으로 이어지고, 코드는 천천히 작성되며, 두 사람이 전체 프로세스에 참여합니다.

Answer 4

나는 가끔 그것을 좋아하지만, 그 스타일을 내내 사용하지는 마세요.때때로 속도의 좋은 변화로 작용합니다.나는 항상 스타일을 사용하고 싶지 않다고 생각합니다.

테스트를 통해 구현을 추진하는 방법을 소개하는 초보자에게 유용한 도구라는 것을 알았습니다.

Answer 5

(우선, Adversarial TDD는 재미있어야 합니다.가르칠 수 있는 기회가 되어야 합니다.인간 지배 의식을 위한 기회가 되어서는 안 됩니다.약간의 유머를 위한 공간이 없다면 팀을 떠나세요.죄송합니다.부정적인 환경에서 낭비하기에는 인생이 너무 짧습니다.)

여기서 문제는 이름이 잘못된 테스트입니다.테스트가 다음과 같다면:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

그럼 이름이 "였던 것 같아요.testGetNameReturnsNameField".이것은 나쁜 이름이지만 즉시 명백하지는 않습니다.이 테스트의 올바른 이름은 "testGetNameReturnsSally".그것이 바로 그것이다.다른 이름은 당신을 잘못된 보안 감각으로 끌어들이고 있습니다.그래서 테스트 이름이 잘못되었습니다.문제는 코드가 아닙니다.문제는 시험도 아니다.문제는 테스트 이름입니다.

대신 테스터가 테스트 이름을 "testGetNameReturnsSally", 그렇다면 이것이 아마도 우리가 원하는 것을 테스트하고 있지 않다는 것이 즉시 명백해졌을 것입니다.

따라서 테스터의 잘못된 선택을 입증하는 것은 구현자의 의무입니다.테스트에서 요구하는 것만 작성하는 것도 구현자의 의무입니다.

프로덕션에서 너무 많은 버그가 발생하는 이유는 코드가 예상보다 덜 수행되었기 때문이 아니라 더 많은 작업을 수행했기 때문입니다.예, 예상되는 모든 사례에 대한 단위 테스트가 있었지만 코드에서 수행한 모든 특수한 엣지 사례에 대한 테스트는 없었습니다. 왜냐하면 프로그래머가 "나도 이 일을 하는 게 낫겠다. 아마 그게 필요할 것"이라고 생각하고 잊어버렸기 때문입니다. 그것.이것이 TDD가 테스트 후보다 더 잘 작동하는 이유입니다.이것이 바로 스파이크가 발생하면 코드를 버리는 이유입니다.코드는 여러분이 원하는 모든 작업을 수행할 수 있지만 아마도 여러분이 필요하다고 생각했지만 잊어버린 작업을 수행할 수도 있습니다.

테스트 작성자가 실제로 원하는 것이 무엇인지 테스트하도록 강요합니다.테스트를 통과하기 위한 코드만 작성하고 그 이상은 작성하지 마세요.

RandomStringUtils는 당신의 친구입니다.