TestCase는 어떤식으로 작성하나요?

2013-07-25 10:20

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)가 없는 듯 하여 질문을 올려 봅니다.

0개의 의견 from FB

2개의 의견 from SLiPP

2013-07-25 12:32

생산과 파괴를 동시에 하는 능력이 사람에게 있는가?

그런 문제의 해결을 위해서 MS의 경우에는 오래전 얘기지만 개발자와 테스터가 따로 있었습니다(현재는 모르겠네요)

저는 과거에는 생산과 파괴를 동시에 할 수 없다고 믿었는데요. 지금은 가능하다 정도로 생각이 많이 바뀌었습니다. 가능한 수준에서 잘한다고 퀄리티를 올릴 때는 더 많은 보완이 필요합니다. 일반적으로 개발자들은 예외보다는 해피패쓰 위주로 테스트를 많이 작성을 하는데요. 그에 대한 보완으로 테스트케이스를 집단으로 작성하는 방법이 있습니다. 우리 회사에는 PSI플래닝 이후에 splint계획을 하는데 splint시작 시에 스펙워크샵을 해서 유저스토리를 잘게 나누고 Acceptance Criteria를 정교하게 작성해야 합니다. 유저스토리의 done기준은 AC를 모두 통과했을 때입니다. 비즈니스 로직은 모두 AC로 표현이 되야 하고 실제 개발자하는 사람이 더 고려할 상황은 트랜잭션과 네트워크 장애와 같은 예외상황을 추가로 고려합니다. SpeccificationByExample이라는 책도 있는데요. 관련 책은 2권정도 별도로 제가 공유드리도록 하겠습니다.

2013-07-26 16:43

TDDBE를 보면 삼각측량법이란 테스트 구현 방식을 소개합니다. 적은 테스트로 비교적 높은 효율을 보일 수 있습니다.

방법은 간단합니다. 첫째 정상적인 케이스에 대한 테스트를 작성합니다. 둘째 비정상적인 케이스에 대한 테스트를 작성합니다. 끝.

또한 CaptureYourBugsToTests는 소프트웨어 개발에 대해 많은 생각을 하게 해줍니다. 무엇을 놓쳤고 어떻게 재현하고 올바로 수정되었는지에 대해서요. 테스트가 누락된 것이 문제라기 보다는... 누락된 것을 쉽게 테스트로 만들어 낼 수 있는지를 확인함으로써 잘 모듈화된 코드인지 판단할 수도 있죠. 이러한 경험이 TDD 잘하게 되는 과정이라고 봅니다.

의견 추가하기

연관태그

← 목록으로