Chapter06. TDD - 테스트 케이스의 신뢰성

< 내용은 다시 공부할 때 개선할 예정 >

 

모든 테스트 케이스에서 입력 값을 동일하게 사용한다면 @BeforeEach 애너테이션을 활용할 수 있음
// 생략

private String value;

@BeforeEach
void given() {
value = "어떤 값";
}

@Test
void when1() {
// ...

asertEquals(expected, value);

// ...
}

@Test
void when2() {
// ...

asertEquals(expected, value);

// ...
}


테스트는 입력 값이 같을 때 항상 결과가 같아야함 ( 해시함수 처럼 )
입력 값은 같지만 어제와 오늘의 결과가 달라지면 안됨
입력 값은 같지만 실행시키는 시점에 따라 결과가 달라진다면 테스트 결과의 신뢰도가 떨어지고 이는 애써 만든 테스트 케이스를 무용지물로 만듬
 예1) 어떤 파일에 들어있는 데이터를 읽는 테스트 케이스가 있을 때 파일의 경로가 같다면 항상 데이터 읽기가 성공해야함

       @Test
       void when1() {
              // ...

              FileUtil fu = new FileUtil();
              int readByte = fu.read("파일 경로");

              assertEquals(2048, readByte);

              // ...
       }

       위 테스트 케이스는 지정한 파일의 경로에 파일이 있을 경우에만 테스트에 성공함
       어제는 해당 파일이 있었지만 오늘은 어떤 이유로 해당 파일이 없을 수도 있음
       또한 어제는 해당 파일의 바이트 수가 2048 이었지만 오늘은 어떤 이유로 해당 파일의 바이트 수가 달라질 수 있음
       이렇게 다양한 이유로 테스트의 결과가 바뀔 수 있으므로 이러한 부분까지 항상 고려해야함

 예2) 어떤 파일이 없다면 테스트 성공인 테스트 케이스가 있을 때 파일의 경로가 같다면 항상 해당 파일이 존재하지 않아야함

       @Test
       void when2() {
              // ...

              assertThrows(NotFoundException.class, () -> {
                     FileUtil fu = new FileUtil();
                     fu.open("파일 경로");
              });

              // ...
       }

       위 테스트 케이스 역시 어떤 이유로 해당 파일이 생겨날 수 있으므로 유의해야함
       위 테스트 케이스의 신뢰성을 보장하기 위해서 아래와 같이 바꿀 수 있음

       @BeforeEach
       void preprocessor() {
              FileUtil fu = new FileUtil();
              file.delete("파일 경로");
       }

       @Test
       void when2() {
              // ...

              assertThrows(NotFoundException.class, () -> {
                     FileUtil fu = new FileUtil();
                     fu.open("파일 경로");
              });

              // ...
       }

예3) 회원 가입 시 이미 사용중인 아이디일 경우 예외를 발생하고 사용중이지 않을 경우 회원가입을 하는 기능의 경우 회원가입을 했을 때 테스트 성공인 테스트 케이스가 있다고 하자
      이 테스트 케이스의 경우 회원가입까지 진행이되므로 테스트 케이스를 최초로 실행시켰을 때는 테스트 성공이지만 두번째 실행부터는 테스트 실패임
      이런식으로 테스트 케이스의 결과가 달라질 수도 있음

      이런 테스트 케이스의 경우에는 테스트 결과 확인 후 테스트로 인해 발생한 시스템의 변화(이 경우에는 DB에 회원 정보 저장)를 원래대로 되돌려야함
      저장된 회원 정보를 삭제하거나 롤백을 사용해 테스트 전으로 시스템을 되돌리는 방법을 선택할 수 있음 

테스트 케이스는 단순히 나열하고 구현한다에서 그치면 안되고 위에서 언급한대로 신뢰성까지 보장할 수 있어야함
따라서 테스트 케이스를 구현하는건 전적으로 개발자의 능력이 중요함
테스트 케이스의 신뢰성을 확보하지 못하면 테스트 케이스의 실패에 무감각해게 됨
그러다 보면 테스트 케이스를 작성하지 않게 되고 결국 TDD를 도입하기 전에 냄새나는 코드를 남발하던 때로 돌아가게됨


테스트 케이스의 신뢰성을 항상 보장할 수 있는건 아님
예를 들어 외부 라이브러리를 사용하는 테스트 케이스의 경우 테스트 케이스의 신뢰성을 개발자가 보장할 수 없음

예를 들어 상품 결제 기능을 구현하기 위해 테스트 케이스를 생각했을 때 테스트 케이스 내 코드 흐름은 아래와 같을 것
 -> 결제 모듈을 호출 해 결제 진행
 -> 결제 모듈이 전달한 결제 정보(실제 결제 정보)와 기대한 결제 정보를 assertEquals 메서드로 비교

이때 테스트 케이스의 신뢰성을 보장하기 위해 생각할 수 있는 것은 아래와 같음
 1. 결제 모듈에 문제가 생겨 호출되지 않는다.
 2. 결제 모듈 내 특정 결제 방법에 문제가 생겨 호출되지 않는다.
 3. 결제 모듈이 결제 정보를 전달하기까지 상당한 시간이 소요된다.
이와 같은 상황은 발생할 가능성은 있지만 결제 모듈을 제공하는 회사로 요청을 해야 만날 수 있는 상황임
( 비록 확률은 극히 낮겠지만... )
이와 같은 상황은 테스트 케이스에서 개발자가 직접 재현할 수 없기 때문에 신뢰성을 확보하지 못하게 만드는 요소임


그러나 위와 같이 외부 요인으로 테스트 케이스의 신뢰성을 확보하지 못할 때 조차도 확보할 수 있게 만들어주는 요소가 있음
대역 이라는 요소임
대역을 사용하면 외부 상황이나 결과를 개발자가 원하는 것으로 대체할 수 있음