테스트 코드를 작성하는 이유

지금 테스트 어떻게 하시나요?

이전까지 일해왔던 레거시 환경에서는 테스트가 서버를 띄우고 Postman 이나 화면에서 직접 입력폼 하나씩 입력하는 방식으로

다양한 use case 에 맞게 수작업 단순노동을 하면서 결과를 보내고 콘솔로 찍히는 로그가 정상인지 확인하는게 일반적인 테스트인줄 알았다.

이 방식은 경험상 단점이 존재한다

• 시간이 많이 필요 : 서버 띄우고 직접 입력폼 하나씩 입력하는 방식은 불필요한 행동이 많아 시간적 소비가 많다
• 유스케이스 기록 : 다양한 유스케이스에 대한 테스트를 기억하기 위해선 엑셀같은 문서에 남겨야한다. 최소 수십개의 테스트를 진행하다 까먹고 다시하거나 잊고 누락하는 경우가 생기기 때문이다
• 상황 대처 느림 : 운영중에 예상치 못한 에러가 발생하면 빠르게 파악하고 수정해서 반영해야하는데, 위와 같은 문제로 해결하는데 시간이 필요하다. 사용자 입장에선 체감상 불편함을 오래 느낄 수 밖에 없다
• 사이드 이펙트 파악 힘듬 : 기능이 수정되면 어떤 문제가 생겼는지 직접 하나씩 확인해도, 예상치 못한 문제가 운영상에서 발생하는 경우가 많다.
• 재사용성 불가능 : 가장 큰 문제점이다. 기능을 재테스트하거나 요구사항이 변경되면 유스케이스를 재정립하고 위의 행동을 처음부터 반복 해야한다.

서비스를 운영하는 입장에서는 문제가 많은 방식이다. 

 

어떻게 테스트 해야할까요?

위와 같은 문제점을 극복하려면 어떻게 테스트를 해야할까?

xUnit 테스트 프레임워크를 이용해서 테스트코드를 작성하면 된다.

다음은 jUnit 를 사용한 테스트 코드다

@DisplayName("String 클래스에 대한 학습 테스트")
public class StringTest {

    @Test
    @DisplayName("문자열 1,2 나누기")
    public void stringTest01() throws Exception {
        String[] result = "1,2".split(",");
        assertThat(result).containsExactly("1", "2");
    }

    @Test
    @DisplayName("문자열 1, 나누기")
    public void stringTest02() throws Exception {
        String[] result = "1,".split(",");
        assertThat(result).containsExactly("1");
    }

    @Test
    @DisplayName("문자열 (1,2) substring 으로 ()제거하기")
    public void stringTest03() throws Exception {
        String data = "(1,2)";
        String result = data.substring(1, data.length()-1);
        assertThat(result).isEqualTo("1,2");
    }

    @Test
    @DisplayName("문자열 abc 뽑아내기")
    public void stringTest04() throws Exception {
        String data = "abc";

        assertEquals(data.charAt(0), 'a');
        assertEquals(data.charAt(1), 'b');
        assertEquals(data.charAt(2), 'c');

        assertThatThrownBy(() -> {
            data.charAt(3);
        }).isInstanceOf(IndexOutOfBoundsException.class)
                .hasMessageContaining("String index out of range: 3");
    }
}

테스트코드 실행결과

 

테스트 코드로 뭘 얻나요?

생소해 보이고 요구사항마다 테스트 코드를 작성하는 시간이 필요하다. 차라리 그 시간에 기능 개발하는게 낫지 않겠니? 소리를 들을 수 있다. 

하지만 작성된 테스트 코드의 장점은 다음과 같다

• 실행가능 설명서 : 엑셀 문서같이 테스트 결과여부 기록이 아닌 실제로 메서드가 요구사항대로 작동하는지 확인가능하다.
• 테스트 시간 단축 : 불필요하게 수작업으로 할 필요가 없다. 코드상에서 테스트할 값만 넣으면 끝난다.
• 유연성 제공 : 수정사항이 생겨도 기존 기능들에 영향을 주는지 손쉽게 확인할 수 있다. 사이드이펙트에 대한 대비가 쉬워진다.
• 재사용성 가능 : 가장 큰 장점이다. 코드만 실행하면 테스트가 끝난다

현재 테스트 코드를 알아가고 있는 입장이지만 더 나은 개발자로 성장하기 위해선 반드시 필수적으로 알고 넘어가야겠다는 생각뿐이다.

 

 

 

https://feel5ny.github.io/2017/12/08/TDD_01/
https://velog.io/@ybg7955/Clean-Code-9장-단위-테스트
https://docs.microsoft.com/ko-kr/dotnet/core/testing/unit-testing-best-practices