TDD를 할경우 대부분의 경우 아래와 같은 순서로 개발 하는듯 합니다.

1. 비지니스 로직에대한 test case생성.
2. test case의 컴파일 오류를 잡아가면서 구현 class작성
3. test case실행
4. 2-3의 과정을 반복하면 모든 test가 통과하도록 작업.

이렇게 대부분의 경우 개발을 하는듯 한데요. 한가지 의문이 든것이 위와같이 개발하는 것은 TDD만을 위한 TestCase작성이지 않을까? 하는 생각이 듭니다. 프로젝트에서 만들어진 대부분의 TestCase들을 확인 해보면 비지니스 로직에 대한 Test코드만 들어있는경우가 많이 있습니다. (TDD의 폐해인걸까요?) 제가 생각 하는 test case는 기본적으로 프로그램의 bug를 찾아내거나 검증하기 위한 것이 기본적인 전제라고 생각 되는데 요즘 TDD가 많이 알려져서 그런지 생성된코드의 비지니스 검증 코드만 test case에 들어있는경우가 많이 보입니다.

그래서 Test Case가 있음에도 불구하고 정상적인 비지니스 로직은 잘 수행이 되는데 예외사항에 대한 test coverage는 처음 class를 작성할때는 대부분 빠뜨리는듯 합니다. 그래서 정상적인 input이 왔을경우는 정상동작을 하지만 보통 test case에 설정한 값이 아니거나(-1, 0, overflow, null...) 정상적인 프로세스가 아닌경우는 오류가 발생 할 때도 가끔 보입니다. - 예를 들어 주문가격이 마이너스(-)로 들어 올 경우에 대한 check...

그래서 아래와 같은 프로세스로 test case를 관리하는것은 어떨까? 하는 생각이듭니다.

1. 비지니스 로직에대한 test case생성.
2. test case의 컴파일 오류를 잡아가면서 구현 class작성
3. test case실행
4. 2-3의 과정을 반복하면 모든 test가 통과하도록 작업. 5. 비지니스 로직을 개발한 개발자가 아닌 다른 개발자가 추자적인 test case 작성.

5. 비지니스 로직을 개발한 개발자가 아닌 다른 개발자가 추자적인 test case 작성. => 이부분을 추가 한 이유는 일단 비지니스 로직을 모두 검증한 후 예외에 대한 테스트를 작성 하여 Test가 해야할 본연의 bug를 찾아 보도록 하는 과정을 추가 한 것입니다. 여기서 포인트는 해당 비지니스로직을 개발 한 개발자가 아닌 다른 개발자(pair를 한다면 driver가 아닌 다른 사람)가 테스트를 작성 해본다는 것입니다. 이유는 보통 제 경험상으로 본인이 개발한 로직을 테스트 하게 되면 되는경우 잘 돌아가는 테스트만 처리 하거나 예외상황의 테스트에 대하여서도 본인이 check한(로직에 들어간) 예외상황만 테스트 하는 경우가 많지 않나 합니다. 그래서 모든 로직을 작성 후 한번더 다른 개발자가 test case에 테스트를 추가 하게 된다면 비지니스를 개발한 개발자가 생각 하지 못한 case까지도 테스트 하게 되는 확률이 높지 않을까? 생각 하여 다른 개발자가 테스트 케이스를 작성 하도록 하는게 좋지 않을까? 합니다.

작성된 테스트 들을 보면서 너무 TDD의 냄새만 나고 진짜 Test(버그를 찾아내는 test)가 없는 듯 하여 질문을 올려 봅니다.