방법론 : 다른 개발자를위한 단위 테스트 작성

소프트웨어 개발과 작문 단위 테스트에 대해 생각하고있었습니다. 나는 다음 아이디어를 얻었다.

개발자 쌍이 있다고 가정 해 봅시다. 각 쌍은 코드의 일부를 담당합니다. 쌍 중 하나는 기능 (쓰기 코드)을 구현하고 두 번째는 단위 테스트를 작성합니다. 테스트는 코드 후에 작성됩니다. 내 생각에 그들은 서로 돕지 만 오히려 별개로 일한다. 이상적으로는 비슷한 크기의 두 가지 기능을 수행 한 다음 테스트 준비를 위해 교환합니다.

이 아이디어에는 몇 가지 단점이 있다고 생각합니다.

• 테스트는 구현에 대해 더 많이 볼 수있는 누군가가 작성합니다.
• 작업은 페어 프로그래밍 (동시에 두 기능)보다 조금 더 빨라져야합니다.
• 테스트와 코드 모두 책임이 있습니다.
• 코드는 최소한 두 사람에 의해 테스트되며
• 코드를 테스트하는 사람이 작성한 코드에서 오류를 검색하면 더 나은 코드를 작성하고 코너를 피하는 데 특별한 동기가 부여됩니다.

코드와 테스트 개발간에 코드 검토를 위해 다른 개발자를 추가하는 것이 좋습니다.

이 아이디어의 단점은 무엇입니까? 이미 알려지지 않은 방법론으로 설명되어 있으며 소프트웨어 개발에 사용됩니까?

추신. 저는 전문 프로젝트 관리자는 아니지만 프로젝트 개발 프로세스에 대해 알고 있고 가장 인기있는 몇 가지 방법론을 알고 있습니다. 그러나이 아이디어는 나에게 친숙하지 않습니다.

생산 코드 작성과 관련 단위 테스트 작성 노력을 분할하기 위해 쌍을 사용하는 일반적인 접근 방식은 드문 일이 아닙니다. 나는 전에도 이런 식으로 개인적으로 짝을 이뤘다. 그러나 생산 코드를 작성하는 사람과 테스트 코드를 작성하는 사람 사이의 엄격한 선이 반드시 결과를 산출하지는 않습니다.

비슷한 접근법을 사용했을 때, 그 쌍은 문제에 대해 이야기하고 공유하는 것으로 시작합니다. TDD를 사용하는 경우 먼저 몇 가지 기본 테스트로 시작할 수 있습니다. TDD를 사용하지 않는 경우 아마도 메소드 정의부터 시작할 것입니다. 여기에서 쌍의 두 멤버는 프로덕션 코드와 테스트 코드를 모두 다루며 한 사람이 각 측면에 중점을 두지 만 프로덕션 코드와 테스트 코드를 개선하는 방법에 대해 이야기합니다.

각 쌍에 두 가지 기능을 제공하는 이점은 없습니다. 당신이 끝내는 것은 일부 기능의 경우 TDD와 비슷하고 다른 기능의 경우와는 다른 것입니다. 당신은 초점을 잃습니다. 실시간 동료 검토의 이점을 얻지 못합니다. 페어링의 주요 이점은 없습니다.

페어 프로그래밍의 실습은 속도가 아니라 품질입니다. 따라서 더 빠른 속도로 진행되는 수정 된 기술을 사용하려고하면 자연에 어긋납니다. 병렬 코드 검토 및 테스트 개발을 통해 고품질 소프트웨어를 구축하면 각 변경 사항에 대해 최소한 두 명 이상이 있고 동료 검토 및 테스트를위한 대기주기를 제거 (또는 감소)하므로 다운 스트림 시간을 절약 할 수 있습니다.

아이디어의 주요 문제는 코드에 대한 테스트를 작성할 수 없다는 것입니다. 코드는 테스트 가능해야합니다.

즉, 모의를 주입하고, 테스트하려는 비트를 분리하고, 변경된 액세스 상태를 확인하고 확인하는 등의 작업을 수행 할 수 있어야합니다.

운이 좋거나 테스트를 먼저 작성하지 않는 한 테스트를 작성할 가능성은 코드를 약간 다시 작성하는 것을 의미합니다. 처음에 코드를 작성하는 사람이 아닌 경우 지연, 회의, 리팩토링 등을 의미합니다.

코드를 작성할 때 유닛 레벨에서 내가 본 주요 문제 는 코드가 불완전하고 단위, 기능 또는 기능이 무엇인지 알더라도 컴파일하고 실행 하고 가장 명백한 버그를 즉시 제거하고 싶습니다. 부분적으로 만 구현되었습니다. 그리고 단위 코드를 실행하려면 구현을 호출하는 프로그램, 일반적으로 단위 테스트 또는 적어도 부분 단위 테스트가 필요합니다. 이것은 반드시 "책에 의한 TDD 스타일"일 필요는 없으며, 그러한 테스트는 테스트중인 코드 이후 또는 코드 전에 작성 될 수 있습니다.

내 장치의 한 버전이 "기능 완료"이고 모든 버그가없는 경우이 방법을 직접 찾을 수 있으면 다른 사람에게 넘겨주고 추가 단위 테스트를 작성하거나 내 코드를 검토 하도록하는 것이 좋습니다. . 그러나 나에게 컴파일러가 경고를 표시하지 않는 한 그것을 넘겨주는 것은 의미가 없습니다. 테스터를 "아직"작동하지 않거나 작동하지 않는 것들에 대해 자세히 설명해야한다는 것을 알고 있다면 너무 빠릅니다. 그 코드에서 여전히 일하고 있기 때문에 2 시간 안에 다르게. 해당 세부 수준에서이를 위해 필요한 통신 오버 헤드는 IMHO가 이점과 균형을 이루지 못할 것입니다.

따라서 추가 단위 테스트를 작성하는 두 번째 개발자에게는 의미가 있지만 단위 테스트를 독점적으로 작성하는 것은 아닙니다 .

다음 상황 중 하나가 발생할 가능성이있는 것 같습니다. 모두 바람직하지 않습니다.

혼동

Ewan이 설명했듯이 테스트 가능하도록 CUT을 변경해야 할 수도 있습니다. 변경 사유가 개발자에게 항상 명백하지는 않으며 (그렇지 않을 수도 있습니다) 이것이 바로 테스트가 먼저 작성된 이유입니다.

투쟁

개발자 A 가 코드를 완성하고 테스트하기를 원할 수 있습니다. 개발자 B 도 개발 중이므로 단위 테스트에 참석하기 위해 코드를 파킹해야 할 수도 있습니다.

상황 전환

경우에도 개발자 B가 작성한 코드를 테스트하기 위해 자신의 개발을 보류 할 의사가 개발자 A를 - 활동의 변화는 비용에 온다.

인력을 두 배로 늘려도 개발 시간이 절반으로 줄어들지 않는다는 것이 수십 년 동안 받아 들여 졌습니다 . 위에서 설명한 요소를 고려할 때이 배열이 어떻게 개선되는지 알기가 어렵습니다.

페어 프로그래밍 및 TDD 와 함께 사용될 때 이것을 Ping Pong Pattern 이라고합니다 .

• A는 새로운 테스트를 작성하고 실패한 것을 확인합니다.
• B는 테스트를 통과하는 데 필요한 코드를 구현합니다.
• B는 다음 테스트를 작성하고 실패한 것을 확인합니다.
• 테스트를 통과하는 데 필요한 코드를 구현합니다.

등등. 리팩토링은 운전하는 사람이 필요할 때마다 수행됩니다.

그러나 두 프로그래머가 다른 컴퓨터를 사용하는 코드를 제안하는 것 같습니다. 별도로 수행하려면 매우 낮은 수준의 사양이 필요합니다. 이것은 민첩한 방법론에 위배됩니다. 모든 변화는 조정되어야합니다. TDD에서 당신은 즉석에서 저수준 desing을하고 있으며 그것은 문제가되지 않습니다. 나는 당신의 aproach가 어떤 종류의 뼈대를 이미 코딩해야한다고 가정합니다.

어쨌든 : 100 % 효율적이지 않더라도 새로운 방식으로 일을 테스트함으로써 많은 것을 배울 수 있습니다. 당신은 그것을 테스트하고 실제 경험을 공유 할 수 있습니다

이 파티에 늦었지만 추가 할 것이 있다고 생각합니다.

이미 알려지지 않은 방법론으로 설명되어 있으며 소프트웨어 개발에 사용됩니까?

피어 테스트를 설명하고 있습니다.

개발자 쌍이 있다고 가정 해 봅시다.

아, 좋은 페어 프로그래밍 .

각 쌍은 코드의 일부를 담당합니다. 쌍 중 하나는 기능 (쓰기 코드)을 구현하고 두 번째는 단위 테스트를 작성합니다. 테스트는 코드 후에 작성됩니다. 내 생각에 그들은 서로 돕지 만 오히려 별개로 일한다.

페어 프로그래밍이 아닙니다.

이상적으로는 비슷한 크기의 두 가지 기능을 수행 한 다음 테스트 준비를 위해 교환합니다.

그것은 분명히 Peer Testing입니다. 여기 ACM 논문이 있습니다 . 나는 이것을했다. 나는 그것이 Peer Review 프로세스 의 공식적인 부분에서 일했습니다 . 도움이 되긴하지만 테스트의 첫 번째 줄은 아니며 고전적인 페어 프로그래밍이 아닙니다.

이것의 또 다른 이름은 Whitebox Testing 입니다. 이 정의는 테스트를 수행하는 사람과 관련이 없지만 테스터가 테스트 대상의 내부 작업을 볼 수 있다는 사실과 관련이 있지만 블랙 박스 테스트와는 달리 무슨 일이야. 블랙 박스는 일반적으로 QA가하는 일입니다.

첫 번째 테스트 라인은 코더의 손에 달려 있습니다. 그것이 아니라면 내가 평평하게 거부하는 코드를 직접 테스트하지 말 것을 요구하는 것입니다. 10 살 때부터 코드를 테스트 해 왔습니다. 당시에는 멋진 단위 테스트로 테스트하지 않았지만 코드는 테스트되었습니다. 내가 그것을 실행할 때마다 테스트되었습니다.

동료 테스터에게 기대하는 것은 테스트에 추가되는 테스트입니다. 피어가 코드를 검토 할 때 발견 한 문제를 풍부하게 명확하게하는 테스트. 자동화 된 테스트로 이러한 문제를 표현함으로써 문제의 의미를 훨씬 쉽게 이해할 수 있습니다. 실제로, 나는 내가하고있는 요점을 보지 못하고 그들에게 문제를 보여주는 가장 좋은 방법을 깨달은 동료와 기술 대화를 나 had습니다. 단위 테스트를 작성하는 것이 었습니다. 그것은 피어 테스트입니다.

이제 코드를 작성하기 전에 작성된 테스트를 원한다면 요구 사항 문서와 같이 공식적인 것은 없습니다.

나는 몇 년 동안 DDT (개발 주도 테스트, 일명 코드 후 테스트), 페어 프로그래밍 및 적록 리 팩터 TDD를 수행했습니다. 포인트 단위로 어설 션에 응답하려면 다음을 수행하십시오.

테스트는 구현에 대해 더 많이 볼 수있는 누군가가 작성했습니다.

테스트를 작성하는 사람은 오버 테스팅없이 커버리지가 좋은 테스트를 작성하기 위해 구현을 최대한 자세하게 알아야합니다 . 전형적인 예는 두 개가 테스트하려는 것을 증명할 때 세 개의 입력으로 테스트하는 것입니다. 코드를 읽음으로써 표면 친숙 함을 얻을 수는 있지만 원래 개발자가 현재 상태에 도달하기 위해 수행 한 작업을 정확하게 이해할 수는 없습니다. 따라서 코드에 대한 이해가 덜 최적화됩니다.

작업은 페어 프로그래밍보다 약간 더 빨라져야합니다 (동시에 두 기능).

왜 그런 말을하는지 모르겠습니다. 누군가 테스트를 작성하는 동안 새로운 기능을 개발하고 있지 않습니다. 두 가지 유형의 작업을 제공하여 다른 사람의 작업 능력을 마술로 두 배로 늘릴 수는 없습니다. 내 경험상 테스트 작성은 일반적으로 프로덕션 코드를 작성하는 것보다 어렵 기 때문에 다른 기능을 작성하는 동안 일부 코드에 대한 테스트를 생산적이고 책임감있게 수행 할 수 없었습니다.

테스트와 코드 모두 책임이 있습니다.

먼저 테스트 는 코드입니다. 비즈니스 테스트 코드는 비즈니스가 두려움없이 소프트웨어 를 변경할 수 있기 때문에 프로덕션 코드만큼이나 중요 합니다. 둘째, 이것은 테스트 및 생산 코드를 작성하는 사람 또는 둘 다를 작성하는 사람과 다르지 않습니다 .

코드는 최소한 두 사람에 의해 테스트됩니다

아니요, 테스트를 작성한 사람 만 테스트합니다. 테스트에 더 많은 시간을 사용하고 싶지 않다면 왜 2시에 멈추는가?

코드를 테스트하는 사람이 작성한 코드에서 오류를 검색하면 더 나은 코드를 작성하고 코너를 피하는 데 특별한 동기가 부여됩니다.

개발자 (심지어 수석 개발자)도 "좋은"코드를 구성하는 아이디어는 매우 다릅니다. 한 사람의 모퉁이 절단은 최대한 빨리 작업 코드를 얻는 다른 사람의 완벽하게 유효한 방법입니다. 이것은 시스템을 비난하고 게임하기위한 레시피입니다.

Red-green-refactor TDD ( 실제로 프로덕션 코드를 작성, 실행, 실패, 프로덕션 코드 만 수정 , 테스트 실행, 성공 및 리팩토링, 테스트 건너 뛰기 또는 스왑하지 않기 전에 단일 테스트 작성 ) 이 단계) 및 코드 검토가 작동합니다.

이 아이디어에는 몇 가지 단점이 있다고 생각합니다.

Le'ts는 하나씩 통과합니다.

테스트는 구현에 대해 더 많이 볼 수있는 누군가가 작성합니다.

따라서 첫 번째 개발자는 구현을 작성하는 데 시간을 보냈으며 이는 확실하지 않습니다. 그런 다음 다른 개발자가 코드를 근거로 자신의 추론을 근거로 테스트를 작성하고 작성하여 코드가 올바른지 여부를 알지 못하며 코드가 수행 해야하는 작업과 관련하여 테스트를 작성하는 것보다 전술적 이점을 얻길 기대합니다. 구현이 잘못되면 테스트 작성에 도움이되지 않을 것입니다.

작업은 페어 프로그래밍보다 약간 더 빨라져야합니다 (동시에 두 기능).

두 개발자가 초기 개발을 마치면 아무도 코드 중 어느 것이 올바른지 알 수 없습니다. 이것은 여전히 ​​확인되어야하며 아무도 완료 된대로 아무도 틱 할 수 없으며 언제 완료 될지 예측할 수 없습니다. 이것을 TDD와 비교하십시오 : 먼저 테스트를 작성한 다음 테스트를 실패로 만든 다음 코드로 전달하십시오. 더 많은 시나리오를 지원하는 코드입니다. 전진 운동입니다.

병렬로 진행하면 두 기능 모두에서 재사용 할 수있는 코드가 두 번 작성되며 비용은 두 배가됩니다.

테스트와 코드 모두 책임이 있습니다.

XP에서 제안한대로 집단 코드 소유권을 살펴보십시오. 코드를 담당하는 사람이 더 많아 질 것입니다. 개발자간에 지식을 공유하는 것이 목표 인 경우 왜 개발자를 분리하려고합니까?

코드는 최소한 두 사람에 의해 테스트됩니다

쌍 TDD로도. 페어링 할 때 두 사람은 작성된 코드가 적합하거나 쓰지 않는다는 데 동의해야합니다. 그 결과 싸움이 발생하면 팀의 일부 사람들이 자아 문제를 잘못 놓았습니다.

코드를 테스트하는 사람이 작성한 코드에서 오류를 검색하면 더 나은 코드를 작성하고 코너를 피하는 데 특별한 동기가 부여됩니다.

오류를 검색한다는 것은 어느 시점에서 오류가 발생했다는 것을 용인했음을 의미합니다. 테스트 작성을 거부하면 오류가 발생하는 데 라이센스가 부여됩니다.

절단 모서리가 의도하지 않은 것일 수 있습니다. 그것이 페어 프로그래밍의 목적입니다. 쌍의 각 구성원은 다른 한 쪽 모서리를 자르지 않도록해야합니다. 우리 모두가 그렇게하기 때문입니다. 그러기 위해서는 자존심을 옷장에두고 사무실을 떠날 때 다시 가져 가야합니다. 사람들이 끊임없이 엄격 해 지길 기대한다면, 일반적인 상황을 고려하지 않고 실패에 대비해야합니다.

XP는 XP의 모든 관행이 서로의 결함을 커버함으로써 서로 강화된다고 명시 적으로 말합니다. XP와 다른 XP 관행에 대한 비판을 듣지 마십시오. 어느 연습도 완벽하지 않고, TDD도 완벽하지 않으며, 페어 프로그래밍이 완벽하지 않으며, 집단 코드 소유권이 완벽하지는 않지만 서로를 포괄합니다.