SpringBoot 기본구조와 단위 테스트 작성

우선 스프링부트를 사용할 때 이클립스가 아닌 인텔리제이를 사용할 것인데

인텔리제이가 이클립스에 비해 갖는 강점에 대해 알아볼 것이다.

- 강력한 추천기능 (Smart Completion)

- 훨씬 더 다양한 리팩토링과 디버깅 기능

- 이클립스의 깃에 비해 훨신 높은 자유도

- 프로젝트 시작할 때 인덱싱을 하여 파일을 비롯한 자원들에 대한 빠른 검색 속도

- HTML과 CSS, JS, XML에 대한 강력한 기능 지원

- 자바, 스프링부트 버전업에 맞춘 빠른 업데이트

그레들 프로젝트를 스프링부트 프로젝트로 변경하기

buildscript {
    //ext는 전역변수 개념, 버전을 전역변수로 고정박아 사용
    ext {
        springBootVersion = '2.1.7.RELEASE'
    }
    //repositories는 각종 의존성 (라이브러리)들을 어떤 원격 저장소에서 받을지 정합니다. 
    //기본적으로 MavenCentral을 많이 사용하지만,
    //최근에는 라이브러리 업로드 난이도 때문에 jcenter도 많이 사용합니다.

    //repositories는 이전부터 많이 사용했지만 본인이 만든 라이브러리를 업로드하기 위해서는 
    //정말 많은 과정과 설명이 필요합니다. 그래서 나온것이 jcenter입니다.
    //jcenter에 업로드하면 maverCenter에도 업로드될 수 있도록 자동화를 할 수 있습니다.
    repositories {
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    }
}

//앞서 선언한 플러그인 의존성들을 적용할 것인지를 결정하는 코드이다.
//아래 4개의 플러그인은 자바와 스프링부트를 사용하기 위한 필수 플러그인이기 때문에 항상 추가하면됨
apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'     //이 플러그인은 스프링부트의 의존성들을 관리해주는 플러그인이라 꼭 추가해줘야 합니다.

group 'com.bahngFamily.jihoon'
version '1.0-SNAPSHOT'
sourceCompatibility = 1.8

repositories {
    mavenCentral()
}

//프로젝트 개발에 필요한 의존성들을 선언하는 곳
dependencies {
    compile('org.springframework.boot:spring-boot-starter-web')
    testCompile('org.springframework.boot:spring-boot-starter-test')
}

build.gradle 파일을 위와 같이 수정하고 나면 우측하단에 Enable auto-Import로 추가

인텔리제이에서 GitHub 단축키 사용

컨트롤 + 쉬프트 + a 로 Action 검색창을 열어 share project on github을 선택하면 레포지토리를 인텔리제이에서 생성가능
커밋을 하고 싶은 경우 : 컨트롤 + k
푸시를 하고 싶은 경우 : 컨트롤 + 쉬프트 + k

단위 테스트

한 가지 짚고 가야할 것이 있는데, TDD와 단위 테스트는 다른 이야기입니다. TDD는 테스트가 주도하는 개발을 이야기합니다. 테스트 코드를 먼저 작성하는 것부터 시작합니다.

 

레드 그린 사이클

1. 항상 실패하는 테스트를 먼저 작성
2. 테스트가 통과하는 프로덕션 코드를 작성
3. 테스트가 통과하면 프로덕션 코드를 리펙토링

반면 단위 테스트는 TDD의 첫 번째 단계인 기능 단위의 테스트 코드를 작성하는 것을 이야기합니다.

TDD와 달리 꼭 테스트 코드를 먼저 작성해야 하는것도 아니고, 리팩토링도 포함되지 않습니다. 순수하게 테스트 코드만 작성하는 것을 말합니다. 여기서는 단위 테스트에서만 이야기 하겠습니다.

위키피디아에서 말하는 테스트 코드로 얻는 이점

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

단위 테스트를 하지 않는 개발자의 개발 방식

1. 코드작성

2. 프로그램(톰캣)을 실행

3. Postman과 같은 API 테스트 도구로 HTTP요청

4. 요청 결과를 System.out.print( )로 눈으로 검증

5. 결과가 다르면 다시 프로그램을(톰캣)을 중지하고 코드를 수정합니다.

 

2~5번은 매번 코드를 수정할 때마다 반복해야합니다.
많은 개발자들은 2번과 5번에서 질색팔색하게 될 것인데 그 이유는 톰캣은 1번만 껐다 켜도 생각보다 엄청난 시간을 잡아먹기 때문이죠. 그래서 자주 껐다 킬수록 보다 많은 개발시간이 소요가 됩니다. 하지만 테스트 코드를 작성하면 이런 문제가 해결되므로 굳이 손으로 직접 톰캣을 껐다 킬 필요는 없습니다.

테스트 코드는 자동검증이 가능합니다.
눈으로 검증하지않고 success 또는 Fail로 한번에 판별이 가능합니다.

개발자가 만든 기능을 안전하게 보호해줍니다.
B라는 기능이 추가되어 테스트합니다. B기능이 잘 되어 오픈했더니 기존에 잘되던 A기능에 문제가 생긴겁니다. 이런 문제는 규모가 큰 서비스에서 종종 발견됩니다. 하나의 기능을 추가할 때마다 너무나 많은 자원이들기 때문에 서비스의 모든 기능을 테스트할 수는 없습니다. 이렇게 새로운 기능이 추가될 때, 기존 기능이 잘 작동되는 것을 보장해주는 것이 테스트 코드입니다.

테스트 코드 작성해보기

src/main/java에 Application 클래스를 생성합니다. 그리고 아래와 같이 코드 작성

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {
  public static void main(String[] args){
    SpringApplication.run(SpringApplication.class, args);
  }
}

@SpringBootApplication으로 인해 스프링부트의 자동설정, 스프링 Bean 읽기와 생성을 모두 자동으로 설정됩니다.
특히나 @SpringBootApplication가 있는 위치부터 설정을 읽어가기 때문에 이 클래스는 항상 프로젝트 최상단에 위치해야합니다.

 

SpringApplication.run로 인해 내장 WAS를 실행함.
내장 WAS란 별도로 외부에 WAS를 두지 않고 애플리케이션을 실행할 때 내부에서 WAS를 실행 하는 것.
이렇게 되면 항상 서버에 톰캣을 설치할 필요가 없게 되고, 스프링 부트로 만들어진 Jar 파일로 실행하면 됩니다.

 

스프링부트에서는 내장 WAS 사용을 권장하는데 그 이유는 '언제 어디서나 같은 환경에서 스프링 부트를 배포' 할 수 있기 때문입니다. 외장 WAS를 사용하면 모든 서버는 WAS의 종류와 버전, 설정을 일치시켜야만 합니다. 새로운 서버가 추가되면 모든 서버가 같은 WAS환경을 구축해야합니다.

 

이제 컨트롤러 만들어보자. 현재 만든 패키지 밑에 web이란 패키지를 추가하고 거기에 HelloController를 만들어보자.

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {
  @GetMapping("/hello")
  public String hello(){
    return "hello";
  }
}

@RestController : 컨트롤러를 JSON을 반환하는 컨트롤러로 만들어줍니다. 예전에는 @ResponseBody를 각 메서드에 선언 했었는데 한번에 사용할 수 있게 되었다.

 

작성한 코드가 제대로 작동하는지 테스트 하겠습니다. WAS를 실행시키지 않고, 테스트 코드로 검증해 보겠습니다.

src/test/java 디렉토리에 앞에서 생성했던 패키지를 그대로 다시 생성해봅니다. 그리고 HelloControllerTest를 생성

import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.test.web.servlet.MockMvc;

@RunWith(SpringRunner.class)
@WebMvcTest(controllers = HelloController.class)
public class HelloControllerTest {
  @Autowired
  private MockMvc mvc;

  @Test
  public void hello가_리턴된다() throws Exception {
    String hello = "hello";

    mvc.perform(get("/hello"))
          .andExpect(status().isOk())
          .andExpect(content().string(hello));
  }
}

@RunWith( -- )

테스트를 진행할 때 JUnit에 내장된 실행자 외에 다른 실행자를 실행시킵니다.

여기서는 SpringRunner라는 스프링 실행자를 사용합니다.

즉, 스프링 부트 테스트와 JUnit 사이에 연결자 역할을 합니다.

 

@WebMvcTest

여러 스프링 테스트 어노테이션 중, Web에 집중할 수 있는 어노테이션입니다.

선언할 경우 @Controller, @ControllerAcvice등을 사용할 수 있습니다.

단, @Service, @Component, @Repository등은 사용불가

여기서는 컨트롤러만 사용하기 때문에 사용하는 것

 

@Autowired

스프링이 관리하는 빈을 주입 받습니다.

 

private MockMvc mvc

웹 API를 테스트할 때 사용합니다.

스프링 MVC테스트의 시작점입니다.

이 클래스를 통해 HTTP, GET, POST 등에 대한 API 테스트를 진행할 수 있습니다.

 

이제 테스트를 실행해보고 아래와 같이 성공하는지 확인해보자

 

 

 

출처 : 스프링 부트와 AWS로 혼자 구현하는 웹 서비스