[TDD Chapter9] 테스트 범위와 종류

🥀 테스트 범위와 종류

예를 들어, 개발 완료 후에 진행하는 테스트를 통합 테스트라고 부르는데, 고객 입장에서 요구한 기능을 올바르게 구현했는지 수행하는 테스트를 인수 테스트라고 부른다. 이처럼, 테스트와 관련 용어는 문맥이나 사용자에 따라 의미가 다를 수 있다.

 

🌻 기능 테스트(Functional Test) 와 E2E 테스트

사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인한다. 이 테스트를 위해서는 시스템을 구동하고 사용하는데 필요한 모든 구성요소가 필요하다.

 

• 사용자가 직접 사용하는 웹 브라우저나 모바일 앱부터 시작하여 데이터베이스나 외부 서비스에 이르기까지 모든 구성 요소를 하나로 엮어 진행
• 브라우저(끝) ~ 데이터베이스(끝)까지 모든 구성요소를 완전히 논리적으로 하나의 기능으로 다룸
• 이에 END TO END (E2E) 테스트라고 불리기도 함.
• QA 조직에서 주로 하는 테스트
• 시스템이 필요하는 데이터 입력하고 결과가 올바른지 확인
• 중요한 것은, 사용자의 입장에서 모든 기능을 확인한다는 것이다.

 

🌻 통합 테스트

시스템의 각 구성요소가 올바르게 연동되는지 확인하는 것이다. 사용자의 입장에서 코드를 테스트하는 것이 아닌, 직접 소프트웨어의 코드르 직접 테스트한다. 

 

• 일반적인 웹 어플리케이션은 프레임워크, 라이브러리, 데이터베이스, 구현한 코드가 주요 통합 테스트 대상

 

🌻 단위 테스트

개별 코드나 컴포넌트가 기대한 대로 동작하는지 확인한다. 여태까지 블로그에 포스팅한 코드는 주로 단위 테스트 코드이다.

• 한 클래스나 한 메서드와 같이 작은 범위를 테스트한다. 
• 일부 의존 대상은 스텁이나 모의 객체등을 이용해서 대역으로 대체한다. 

 

🌻 테스트 범위간 차이

통합 테스트	기능 테스트	단위 테스트
DB나 캐시 서버와 같은 연동 대상을 구성, 테스트 시나리오를 위해 많은 노력	웹 서버를 구동하거나 모바일 앱을 폰에 설치, 테스트 시나리오를 위해 많은 노력	테스트 코드만 빼두면 됨
DB 연결, 소켓 통신, 스프링 컨테이너 초기화 등과 같이 실행 속도 느리게 하는 요인이 많음	브라우저나 앱을 구동하고 화면의 흐름에 따라 알맞은 상호작용	서버를 구동하거나 DB를 준비할 필요가 없음, 의존 대상을 대역으로 대체
통합 테스트나 기능 테스트로는 결과 확인이 어려울 때, 단위 테스트와 대역을 조합하여 상황을 만들고 결과를 확인함.

테스트 코드를 작성하는 개발자는 단위 테스트와 통합 테스트를 섞어서 작성한다. 어느 테스트를 더 많이 작성해야한다는 규칙은 없지만, 주로 단위 테스트를 많이 작성하는 편이라고한다. 

 

단위테스트를 주로 사용한다고는 하지만, 각 구성 요소가 올바르게 연동되는지 확인하기 위해서 통합 테스트는 필요하다.

 

🌻 테스트 범위에 타른 테스트 코드 개수와 시간 

기능, 통합, 단위 테스트 등 전 범위에 대해 테스트를 자동화하는 시도가 증가하고 있으며, 이를 통해 고품질의 소프트웨어를 더 빠르게 출시하고자하는 전략이 늘어나고 있다. 

 

기능 테스트는 테스트하기위한 모든 환경이 갖춰져 있어야 하기 때문에, 자동화하거나 다양한 상황별로 테스트하기 가장 어렵다. 따라서, 정상적인 경우와 몇 가지 특수한 상황을 테스트 범위를 잡아 테스트를 진행한다. 

 

통합 테스트는 기능 테스트에 비해 제약이 덜하다. 기능 테스트에 비해 상대적으로 실행 시간이 짧고 상황보다 유연하게 구성할 수 있기 때문에 보통 기능 테스트보다 통합 테스트를 더 많이 사용된다. 

 

단위 테스트는 통합 테스트로도 만들기 힘든 상황을 쉽게 구성할 수 있다. 작은 단위를 대상으로 테스트 코드르 만들고 더 다양한 상황을 다루기 때문에 통합 테스트보다 더 많이 사용된다. 

 

 

기능, 통합에서 모든 예외 상황을 테스트하면 테스트를 다루는 내용이 중복되기 때문에 단위 테스트는 줄어든다. 테스트 속도는 단위 테스트가 다른 테스트들보다 속도가 월등히 높기 때문에 가능하면 단위 테스트에 다양한 상황을 다루고, 통합과 기능에서는 주요 상황에 초점을 맞춰 코드를 작성해야한다. 

속도가 느려지면, 소프트웨어 품질 저하로 이어질 수 있기 때문에 가능하면 빠른 시간 내에 테스트를 실행할 수 있도록 해야한다.

 

 

🥀 외부 연동이 필요한 테스트 예

소프트웨어는 다양한 외부 연동이 필요하다. 외부 연동 대상은 쉽게 제어할 수 없기 때문에 연동해야 할 대상이 늘어날수록 통합 테스트도 힘들어진다. 

 

모든 외부 연동 대상을 통합 테스트에서 다룰 수 없지만, 일부 외부 대상은 어느정도 수준에서 제어가 가능하다.

 

🌻 스프링 부트와 DB 통합 테스트

Spring Boot, Spring Data JPA, MySQL 기술을 사용했다. 

 

/**
* 통합 테스트
*/
@SpringBootTest
@RequiredArgsConstructor
public class UserRegisterTest {

    private final UserRegister register;
    private final JdbcTemplate jdbcTemplate;

    @Test
    void 동일한_ID가_이미_존재하면_익셉션(){
        // 상황 insert 쿼리 실행
        jdbcTemplate.update(
                "insert into user values(?, ?, ?)" +
                        "on duplicate key update password = ?, email = ?",
                "cbk", "pw", "cbk@cbk.com", "pw", "cbk@cbk.com");

        // 실행 결과 확인
        assertThrows(DupIdException.class, () ->
                register.register("cbk", "strongpw", "email@email.com"));
    }

    @Test
    void 존재하지_않으면_저장함(){
        // 상황 delete 쿼리 실행
        jdbcTemplate.update("delete from user where id = ?", "cbk");

        // 실행
        register.register("cbk", "strongpw", "email@email.com");

        // 결과 확인 select 쿼리 진행
        SqlRowSet rs  = jdbcTemplate.queryForRowSet(
                "select * from user where id = ?", "cbk"
        );

        rs.next();
        assertEquals("email@email.com", rs.getString("email"));
    }

}


/**
* 단위 테스트
*/
@SpringBootTest
public class UserRegisterTest {
    private UserRegister userRegister;
    private MemoryUserRepository fakeRepository = new MemoryUserRepository();
    // 생략

    @Test
    void 이미_같은_ID_존재하면_가입_실패(){
        // 단위 테스트는 **대역**을 이용한 상황 구성
        fakeRepository.save(new User("id", "pw1", "email@email.com"));

        assertThrows(DupIdException.class, () ->{
            userRegister.register("id", "pw2", "email");
        });
    }
}

 

통합 테스트는 실제로 DB를 사용한다. 동일한 테스트를 여러번 실행해도 결과가 같게 나와야하므로 테스트코드에서 DB 데이터를 알맞게 제어해야 한다. 

 

 

🌻 WireMock을 이용한 REST 클라이언트 테스트

통합 테스트하기 어려운 대상이 외부 서버이다. 

public class CardNumberValidator {

    // 7장과 달리 추가된 코드
    // 생성자로부터 server url 을 받아 하드코딩이 되지 않도록 함.
    private String server;

    public CardNumberValidator(String server){
        this.server = server;
    }
    //
    public CardValidity validate(String cardNumber){
        HttpClient httpClient = HttpClient.newHttpClient();
        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create(server + "/card"))
                .header("Content-Type", "text/plain")
                .POST(HttpRequest.BodyPublishers.ofString(cardNumber))
                .build();
        try{
            HttpResponse<String> response =
                    httpClient.send(request, HttpResponse.BodyHandlers.ofString());
            switch (response.body()){
                case "ok" : return CardValidity.VALID;
                case "bad" : return CardValidity.INVALID;
                case "expired" : return CardValidity.EXPIRED;
                case "theft" : return CardValidity.THEFT;
                default : return CardValidity.UNKNOWNS;
            }
        }catch (HttpTimeoutException e){
            return CardValidity.TIMEOUT;
        }
        catch (IOException | InterruptedException e){
            return CardValidity.ERROR;
        }
    }
}

 

위 클래스 자체를 테스트하려면 정해진 규칙에 맞게 통신할 수 잇는 서버가 필요한데, 외부의 카드 정보 제공 api와 통신할 때 원하는 상황을 쉽게 만들 수 없다. 이 때, 사용하는 것이 WireMock이다. WireMock을 사용하여 올바른 응답이나 타임아웃과 같은 상황에 대해 테스트 할 수 있다. 

 

public class CardNumberValidatorTest {
     private WireMockServer wireMockServer;

     @BeforeEach
    void setUp(){
         wireMockServer = new WireMockServer(options().port(8089));
         wireMockServer.start();
     }

     @AfterEach
    void tearDown(){
         wireMockServer.stop();
     }

     @Test
    void valid(){
         wireMockServer.stubFor(post(urlEqualTo("/card")) // url, post 요청
                 .withRequestBody(equalTo("1234567890")) // 요청 몸체가 "1234567890 과 요청이 같으면
                 .willReturn(aResponse()
                         .withHeader("Content-Type", "text/plain") // header는 다음과 같이
                         .withBody("ok"))); // 응답 몸체가 ok로 값을 전달해줌
         CardNumberValidator validator = new CardNumberValidator("http://localhost:8089");
         CardValidity validity = validator.validate("1234567890");
         assertEquals(CardValidity.VALID, validity);
     }

     @Test
     void timeout(){
         wireMockServer.stubFor(post(urlEqualTo("/card"))
                 .willReturn(aResponse().withFixedDelay(5000)));

         CardNumberValidator validator = new CardNumberValidator("http://localhost:8089");
         CardValidity validity = validator.validate("1234567890");
         assertEquals(CardValidity.TIMEOUT, validity);
     }
}

 

WireMockServer

• 테스트 실행 전 시작, 실제 HTTP 서버가 뜬다
• 테스트에서 WireMockServer의 동작을 기술
•  HTTP 연동을 수행하는 테스트 실행
• 테스트 실행 후에 WireMockServer 중지

 

🌻 스프링부트 내장 서버를 이용한 API 기능 테스트

모바일 앱에서 회원 가입을 위해 사용하는 회원 가입 API가 올바르게 JSON을 응답하는지 검증하는 코드를 작성해보자. 

회원 가입은 매우 중요하기 때문에 회원 가입 API를 검증하는 테스트 코드를 작성하여 검증 과정을 자동화하면 담당자가 수동으로 테스트하는 시간을 줄일 수 있다.

 

@SpringBootTest(
        webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT
)
@RequiredArgsConstructor
public class UserApiE2Test {
    private final TestRestTemplate testRestTemplate;

    @Test
    void weakPwResponse(){
        String reqBody = "{\"id\":\"id\", \"pw\":\"123\",\"email\":\"a@a.com\"}";
        RequestEntity<String> request = RequestEntity.post(URI.create("/users"))
                .contentType(PageAttributes.MediaType.APPLICATION_JSON_UTP8)
                .body(reqBody);
        
        ResponseEntity<String> response = testRestTemplate.exchange(
                request, String.class
        );
        
        assertEquals(HttpStatus.SC_BAD_REQUEST, response.getStatusCode());
        assertTrue(response.getBody().contains("WeakPasswordException"));
    }
}

 

TestRestTemplate은 스프링 부트가 테스트 목적으로 제공하는 것으로서, 내장 서버에 연결하는 RestTemplate이다. 임의의 포트를 사용하여 내장서버를 구동하도록 설정을 해두었다.