[혼자 구현하는 웹서비스] 2. (1) 테스트 코드

0. 개요

1. 테스트 코드 소개, TDD와의 차이점

2. 테스트 코드 작성하기

 

0. 개요

많은 회사 채용 과정에 테스트 코드 작성 경험을 우대한다. 테스트 코드의 중요성.

 

1. 테스트 코드란?

TDD (test-driven development)와 단위 테스트 (Unit test)는 분명하게 다른 것이다.

 

TDD는 말 그대로, 테스트가 주도하는 개발 과정을 의미한다. 테스트 사이클은 다음과 같은 3단계 과정을 거친다.

i. 항상 실패하는 테스트를 작성하고 (red),

ii. 테스트가 통과하는 프로덕션 코드를 작성하고 (green),

iii. 테스트가 통과하면 프로덕션 코드를 리팩토링한다 (refactor).

 

단위 테스트는 TDD의 첫 번째 단계인 '기능 단위의 테스트 코드를 작성' 하는 것을 의미한다.

테스트 코드를 꼭 먼저 작성해야 하지도 않고, 리팩토링도 포함되지 않는다.

즉, 순수하게 테스트 코드를 작성하는 것만을 의미한다.

 

테스트 코드에 대해 먼저 접한 후, TDD를 배워 보는 것이 도움이 될 것이다.

도움이 되는 내용: https://repo.yona.io/doortts/blog/issue/1 

"TDD 실천법과 도구" 책 전체를 PDF 공개합니다.

 

테스트 코드를 작성함으로써 얻을 수 있는 이점은 다음과 같다 (출처: 위키피디아):

 

• 단위 테스트는 개발단계 초기에 문제를 발견하게 도와 준다.
• 단위 테스트는 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존 기능이 올바르게 작동하는지 확인할 수 있습니다. (회귀 테스트 등)
• 단위 테스트는 기능에 대한 불확실성을 감소시킬 수 있다.
• 단위 텐스트는 시스템에 대한 실제 문서를 제공한다. 즉, 단위 테스트 자체가 문서로써 사용될 수 있다.

테스트 코드가 없으면 결과를 눈과 손으로 직접 확인해야 한다.

테스트 코드를 이용하면 이를 자동으로 검증할 수 있고, 이를 확인하려고 프로그램 (톰캣 등)을 계속 실행-종료를 반복할 필요가 없다.

또, 개발자가 만든 기능을 안전하게 보호해 준다. 현업에서 새로운 기능이 추가되면서 기존의 기능과 충돌을 일으키는 경우가 있는데, 기존의 기능에 대해 테스트 코드를 제대로 작성해 두었다면 문제를 조기에 찾을 수 있다.

 

테스트 코드 작성을 도와주는 프레임워크들이 있다.

대표적으로 xUnit이 있는데, x는 개발환경을 나타낸다. 예를 들어, JUnit - Java, DBUnit - DB, CppUnit - C++, NUnit - .net와 같은 식이다.

JUnit은 현재 JUnit 5가 최신 버전이지만, 많은 회사에서는 JUnit 4를 사용하고 있다고 한다. 본 글에서도 JUnit 4를 이용하여 테스트코드를 작성해 보겠다.

2. 테스트 코드 작성하기

 

패키지 생성하기

기존에 만들었던 프로젝트를 통해 패키지를 생성한다.

src/main/java 디렉토리를 우클릭 후, New -> Package를 선택하면 된다.

패키지의 이름은 웹 사이트 주소의 역순으로 한다. 예를 들어 blog.katfun.com 이라는 주소가 있다면, 패키지명은 com.katfun.blog 가 되는 식이다.

패키지를 생성할 때 기본으로 주어지는 org.example을 사용했으므로, 뒤에 현재 프로젝트명인 springboot를 붙여서 org.example.springboot로 패키지명을 정했다.

 

패키지를 생성했다.

생성한 패키지 아래에 Java 클라스를 생성한다.

위의 과정과 마찬가지로, 패키지를 우클릭한 후, New -> Java Class를 선택하면 된다. 클라스 명은 Application이라고 하였다.

 

클라스 생성

클라스의 코드를 아래와 같이 작성하였다.

 

Application.java

위 코드에 대해 간단히 짚고 넘어가자면 (대부분 주석으로 이미 적어두긴 했다),

1. Application.java는 앞으로 만들 프로젝트의 메인 class가 된다.

2. @SpringBootApplication의 위치부터 설정을 읽어가므로, 이 클라스는 항상 프로젝트의 최상단에 위치해야 한다.

3. main 메소드 내에서 실행한 SpringApplication.run은 내장 WAS를 실행시킨다.

 

3번에 대해 조금 더 자세히 다루어 보겠다.

내장 WAS (web application sever)란, 별도의 외부에 WAS를 두지 않고 애플리케이션을 실행할 때 내부에서 WAS를 실행하는 것을 말한다.

이렇게 되면 항상 서버에 톰캣을 설치할 필요가 없게 되며, 스프링 부트로 만들어진 jar 파일로 실행하면 된다.

꼭 스프링 부트에서만 내장 WAS를 사용할 수 있는 것은 아닌지만, 스프링 부트에서는 내장 WAS를 사용할 것을 권장하고 있다. 언제 어디서나 같은 버전으로 스프링 부트를 배포할 수 있기 때문이다.

외장 WAS를 사용하면, 모든 서버는 WAS의 종류와 버전, 설정을 일치시켜야 한다. 서버가 여러 대가 되면 시간도 많이 들고, 실수할 여지도 많아지므로 관리에 어려움이 생기게 된다.

 

Application 클라스를 만들었으니, 다음은 테스트를 위한 Controller를 만들어 본다.

현재 패키지 하위에 web이라는 패키지를 만들어 보자.

 

새 패키지 만들기

앞으로 컨트롤러와 관련된 클라스들은 모두 이 패키지에 담기로 한다.

 

테스트해볼 컨트롤러를 만들어 보자. 아까 했던 것과 같이 New -> Java Class를 선택하면 된다.

클라스의 이름은 HelloController로 한다.

 

클라스를 만들고 난 화면.

생성한 후에 간단한 API를 만들어 보자.

 

간단한 API

이제 이 프로젝트는 /hello로 요청이 오면 문자열 hello를 반환하는 기능을 가진다.

 

위 코드가 제대로 작동하는지 테스트를 해 보자.

WAS를 실행시키지 않고, 테스트 코드를 통해 검증해 보고자 한다.

src/test/java 디렉토리에, 앞에서 생성했던 패키지를 그대로 다시 생성해 보자 (org.example.springboot).

 

src/test/java/org.example.springboot/web

생성된 클라스에 다음과 같은 테스트 코드를 작성한다.

 

테스트 코드

위 코드를 실행해 보자.

메소드 왼쪽의 화살표를 클릭한다.

 

클릭

테스트가 제대로 동작한다면, 테스트 결과가 출력되게 된다.

 

테스트 코드 정상 동작, 테스트 통과 실패

테스트 통과가 실패했다. 무슨 일일까?

앞서 작성한 테스트 코드의 경우, /hello라는 요청을 받았을 때 "hello" 라는 문자열을 반환하면 성공이다.

 

그렇다면 앞서 작성한 main의 HelloController.java를 보자.

"/Hello" 라고 되어 있다!

14번째 줄에, /"Hello" 라고 되어 있다.

즉 입력을 /Hello라고 요청 받아야 hello를 리턴하는 코드인 것이다!

대문자를 소문자로 수정하고 다시 실행해 보자.

 

 

테스트를 통과했다!

이런 방식으로 테스트를 자동화 할 수 있다.

그렇다면 우리가 수동으로, 직접 두 눈으로 결과를 확인해보고 싶다면 어떻게 하면 될까?

 

앞서 작성한 Application.java를 열고, main 메소드를 실행해 보자.

 

Application.java의 main 메소드를 실행하고, Run을 누르자.

 

실행 로그

스프링 부트가 실행되고 로그가 출력된다.

로그를 잘 보면, Tomcat initialized with port: 8080 (http) 라는 문구를 볼 수 있다.

웹 브라우저를 열어 localhost:8080/hello 를 입력해보자.

 

수동 검증

테스트 코드를 통해 확인하고자 했던 결과와 일치하는 것을 확인할 수 있다.

 

 

*이 글은 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스' (프리렉, 이동욱 저)를 공부하며 내용을 정리한 글입니다.