테스트 주도 개발-누가 테스트를 작성해야합니까?

12

원래는 테스트를 작성하는 것이 개발자의 의무이지만, 많은 경우에 / 성숙한 개발자는 이러한 경우가 80 %까지 커버리지를 제공하지 않는 것으로 나타났습니다.
개발자 대신 지정된 프로젝트에 대한 모든 테스트를 작성하는 전담 QA 담당자가 있습니까?
그것에 대해 어떤 단점이 있습니까?

development-process tdd

— Itay Moav-말리 모프 카
소스

2

TDD가 모든 코드에 대한 모든 테스트를 작성한 다음 코드를 작성한다는 의미는 아닙니다. 용어입니다. 그러나 실용적인 접근 방식은 테스트를 작성한 다음 작은 반복으로 코드를 작성하는 것입니다. 더 병렬 방식으로 접근합니다. 모든 테스트를 미리 작성하는 것은 리팩토링이 불가피하게 드러날 것이므로 시간 낭비입니다.

— Aaron McIver

19

테스트 주도 개발에서 테스트는 개발자가 작성해야합니다. 그렇지 않으면 개발자 이외의 사람이 개발을 추진하고 있습니다.

개발자가 아닌 사람에게 테스트를 작성하는 즉시 개발자가됩니다.

TDD에 대한 나의 경험은 테스트 코드를 작성하는 것이 종종 프로덕션 코드를 작성하는 것보다 어렵거나 어렵다는 것입니다. 따라서 우수한 단위 테스트 / 통합 테스트 코드를 작성할 수있는 리소스가 있다면 해당 테스트를 통과하는 프로덕션 코드를 작성해야합니다.

— 에릭 윌슨
소스

1

숙련 된 자세를 가진 두 명의 유사한 개인이 있다면 테스트와 코드 사이를 전환 / 교체하는 한 쌍의 프로그래밍 방식으로 TDD에 접근 할 수 있습니다. 그들을 테스터 / 프로그래머 / 코드 원숭이라고 부릅니다.

— Aaron McIver

그리고 아마도 매분마다 write_test-write_code-run_test가 주어지면 진행 속도를 없애 버릴 것입니다.

— Frank Shearar

7

QA의 임무는 완전히 다른 종류의 테스트 (예 : 유용성 / 통합 테스트)를 수행하는 것입니다. 그들은 실제로 코드에 사용 된 기술을 알 필요가 없습니다.

낮은 코드 적용 범위가 걱정되는 경우 개발자를 훈련시켜야합니다. 예를 들어 코드 범위가 증가 할 때까지 새로운 기능에 대한 작업을 중지합니다. 일부 조직에서는 발견되지 않은 코드를 체크인 할 수없는 저장소에 사전 커미트 후크가 있습니다.

마지막으로, '순수한'TTD에는 발견되지 않은 코드가 없어야합니다 (테스트를 먼저 작성하므로). 그러나 더 낮은 코드 적용 범위가 허용되는 경우가 있습니다 (사람들이 그것에 대해 논쟁하지만). 예를 들어 POJO의 게터 / 세터에 대한 테스트 작성은 시간 낭비라고 주장하는 사람들도 있습니다.

— 맥
소스

2

이 경우에도 80 %의 보장 범위를 제공하지 않습니다

관리상의 문제 일 수 있습니다.

또는 관련이 없을 수 있습니다.

첫째, 80 %와 100 % 범위의 차이는 혜택이 거의 없기 때문에 많은 비용이들 것입니다.

"범위"는 무엇이든 의미 할 수 있습니다. 코드 줄, 논리 경로 등. 논리 줄이 아닌 코드 줄을 의미한다고 생각합니다.

일부 논리 경로는 "검사로"꽤 잘 테스트됩니다. 코드는 분명하고 if 문이 없으며 복잡성이 매우 낮으며 추가 테스트가 필요하지 않습니다.

20 % 더 많은 테스트가 항상 20 % 더 좋은 것은 아닙니다.

둘째. 관리 문제입니다. 경영진이 100 % 보장 범위를 원할 경우 80 % 적용 범위를 "출시하기에 충분"하지 않고 100 % 적용 범위에 대한 보상 시스템을 마련해야합니다.

더 많은 테스트를 작성하기 위해 QA 담당자를 추가해도 큰 도움이되지 않습니다.

더 많은 테스트를 작성하기 위해 개발자를 추가하는 것은 100 % 테스트 범위에 도달해야합니다.

— 로트
소스

100 % 보장에 대해 누가 말했습니까?

— Eric Wilson

@ FarmBoy : 질문은 80 %의 범위가 충분하지 않다는 것을 암시합니다. 충분히 좋은 것은 무엇입니까? 일반적으로 마법의 숫자는 100 % 적용 범위입니다.

— S.Lott

1

하지만 코치 님은 항상 110 %를 주라고 말씀하셨습니다. 왜 그 정도의 보상을 요구할 수 없습니까? ;-P

— Berin Loritsch

@Berin Loritsch : 200 % 뒤쳐져 있습니다.

— S.Lott

1

@Job : "일부 QA 담당자는 코드를 작성할 수 있습니다". 권리. 그런 다음 개발자가되며 이는 좋은 일입니다.

— S.Lott

2

IMHO 단위 테스트는 품질 보증 프로세스가 아닙니다. 개발자의 피드백 루프를 줄임으로써 개발 속도를 높이는 것에 관한 것입니다. 구성 요소 사용법 (다른 개발자의 구성 요소)에 중점을두고 구성 요소 (일명 단위)를 작성하는 사람이 수행해야합니다.

기능 테스트는 QA 팀이 수행 할 수있는 QA 프로세스입니다. 이는 개발자가 수행 할 수 있지만 개발자가 사용자가 응용 프로그램을 사용할 수있는 모든 방법을 모를 수 있으므로 개발자가 아닌 것이 좋습니다.

둘 다 TDD 방식으로 수행 할 수 있습니다.

— 히스 릴리
소스

2

TDD는 테스트뿐만 아니라 디자인에 관한 것입니다. 테스트를 통과하기위한 코드 작성은 일반적으로 더 작고 유지 보수가 쉬운 코드로 이어집니다. 다른 사람에게 테스트를 작성하도록 위임하면 좋은 코드를 작성해야 할 책임도 위임됩니다.

또한 적용 범위는 코드 품질에 대해 알려주지 않으며 도메인 규칙이 적용되는지 여부도 알려주지 않습니다.

— 페르난도
소스

0

최소 80 %의 적용 범위가 필요한 경우 몇 가지 작업을 수행해야합니다.

개발자에게 적용 범위 수준을 결정하고 사과가 사과인지 확인하는 데 필요한 도구를 제공하십시오. 적용 범위를 측정하는 방법은 여러 가지가 있습니다.
그 위업을 달성하기위한 보상 / 인센티브를 제공하십시오. 프로그래머는 자신이 지불 할 것이라고 느끼는 일만 할 것입니다. 50 %의 커버리지가 품질을 보장하고 모든 작업을 수행 할 수있을 정도로 충분하면 이것이 바로 그 일입니다.

마지막으로 의도 된 실행 경로와 의도하지 않은 실행 경로 간에 차이가 있음을 이해하십시오 . 테스트 주도 코드를 작성하는 과정에서 독립 if 문 쌍이 필요하다는 것을 증명했을 수 있습니다. 결과적으로 사용 가능한 잠재적 인 4 개의 실행 경로 중 2 개에 대한 테스트가 있습니다. 독립적 인 if 문을 하나 더 추가하면 8 개의 실행 경로가있을 수 있습니다 (즉, 기하 급수적으로 증가 함).

TDD가 모든 잠재적 인 실행 경로를 반드시 예측할 필요 는 없으므로 완료 하기 위해 작성해야 할 수도 있지만 해당 경로를 테스트 할 필요 가 없기 때문에 작성되지 않은 많은 테스트가 있습니다. 간단히 말해서, TDD는 적용 범위를 보장 하지는 않지만 존재하는 코드에 대한 이유 를 입증하기위한 적어도 하나의 테스트가 있음을 보증 합니다.

— 베린 로리 치
소스