TDD에서는 모든 사람이 단위 테스트 작성 방법과 개발 방법에 대해 이야기합니다. 전 사이클을 알고 있지만 요구 사항에서 단위 테스트를 만드는 것에 대해 몸이 말하는 것은 아닙니까? 나는이 단위 테스트를 개발하기 전에 항상 테스트 목록을 만드는 것이 좋다는 문학 어딘가를 읽었습니다. 내 질문은 : 정확히 TDD에서 단위 테스트를 작성하기 전에 따라야 할 절차 (단계)는 무엇입니까? 단위 테스트가 공식 표준을 사용하지 않고 요구 사항에서 직접 작성되었거나 테스트 목록이 개발되기 전에 만들어 졌는지 여부를 의미합니다.테스트 주도 개발의 테스트 목록 개념
테스트 목록은 다음 테스트 사례를위한 임시 리포지토리입니다. 전적으로 비공식입니다.
테스트 목록의 주요 역할은 마음을 여는 것입니다. 새로운 테스트에 대해 생각할 때, 목록의 마지막에 그것을 적어두기 만하면됩니다. 잊어 버리고 잊어 버리고 문제의 초점을 바로 잡으십시오.
테스트 및 목록을 작성하는 절차가 없으므로 요구 사항에서 UML 모델을 만들 때와 마찬가지입니다. 당신은 문제에 대해 생각하고 디자인을 만듭니다. 디자인이 완료되면 구현을 시작합니다. TDD를 사용하면 테스트 관점에서 문제를 생각하면 목록에 몇 가지 테스트를 기록하고 목록에서 간단한 테스트로 시작할 수 있습니다. 언제든지 목록에 테스트를 추가 (또는 제거) 할 수 있습니다.
bowling game episode은 요구 사항에서 단위 테스트로의 전환을 보여주는 짧은 읽기입니다. 그것은 어떤 시험 목록도 언급하지 않는다.
단위 테스트 소스 파일의 맨 아래에 주석으로 내 테스트 목록을 유지합니다.
void test_foobarShallFailWithNull(void) {
...
}
// the tests I *may* write next
//void test_foobarShallFailWhenX(void)
//void test_foobarShallWorkWhenY(void)
TDD를 할 때 요구되는 테스트는 필요한 단위 테스트를 직접 확인하는 데 사용됩니다. 이론적으로 개발자는 전체 요구 사항 집합 중 하나의 작은 측면을 선택하고 해당 측면에 대해 단일 단위 테스트를 작성한 다음 단일 테스트를 통과하는 가장 간단한 코드를 작성합니다. 실제로 요구 사항과 선택한 요구 사항의 측면은 개발자가 한 번에 여러 개의 단위 테스트를 식별하도록 유도 할 수 있습니다. 테스트 목록은 주차장으로 사용되므로 개발자는 한 번에 한 테스트에만 집중할 수있는 반면 테스트 아이디어를 잃어 버릴 염려가 없습니다.
너무 무겁거나 정식적인 것은 아무것도 아니므로 작업을 시작하기 전에 종이 (또는 스프레드 시트 또는 텍스트 파일)에 대해 생각할 수있는 모든 테스트를 기록해 두십시오.
그런 다음 목록을 처리하여 하나씩 선택하고 완료되면 건너 뜁니다. 구현 중에 새로운 테스트를 생각해 내면 테스트 목록에 추가하고 현재 테스트에 계속 집중합니다. 당신이 당신의 명부에 더 이상 시험이 없으면, 당신은 끝난다.
TDD에 대한 단위 테스트는 세분화되어 있으며 대부분의 경우 요구 사항/사양은 그렇지 않습니다. 따라서 요구 사항 문서를 사용하여 시스템 수준의 수락 테스트를 수행 할 수 있습니다. 또한 특정 수락 테스트를 통과하려면 TDD를 사용하여 구현하는 많은 작업이 필요합니다.
나는 equivalence partitioning을 사용하여 테스트 사례 목록을 생성합니다.
필자는 요구 사양이 단위 테스트보다 기능 테스트에 영향을 줄 것이라고 생각합니다. –