일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 백준
- 자바
- 세그먼트 트리
- 이펙티브 자바
- UML
- 포트앤어댑터 아키텍처
- equals
- 비트마스크
- springboot
- 문자열
- JPA
- 데이터 flow
- disjoint set
- ddd
- spring security
- DP
- docker
- Redis
- 위상정렬
- java
- dataframe
- 다익스트라
- 파이썬
- 알고리즘
- series
- BFS
- 스프링
- 헥사고날 아키텍처
- pandas
- dfs
- Today
- Total
코딩못하는사람
[스프링 부트+AWS]2. 스프링 부트에서 테스트 코드 작성 본문
TDD (Test-Driven Development)란?
이름에서 알 수 있듯이 테스트가 주도하는 개발이라는 뜻이다.
종료조건을 테스트 코드로 미리 정하고 그에 맞춰서 테스트를 통과시키기 위해 개발해 나간다고 생각하면 이해하기 쉽다.
- 항상 실패하는 테스트를 먼저 작성한다(RED)
- 테스트가 통과하는 프로덕션 코드를 작성한다(GREEN)
- 테스트가 통과하면 프로덕션 코드를 리팩토링한다.
- 위 3단계를 반복하며 점진적으로 개발을 완료시킨다.
프로덕션 코드-프로젝트의 로직을 포함하고 제품(어플리케이션)에서 실행되는 시스템의 부분을 가리킨다
단위 테스트(Unit Test)란?
TDD의 첫 단계인 기능 단위의 테스트 코드를 작성하는 것이다.
TDD를 하는 것이 아닌 순수하게 테스트 코드를 작성하는 것을 의미한다.
왜 테스트 코드를 작성할까?
- 단위 테스트는 개발단계 초기에 문제를 발견할 수 있게 해준다.
- 단위 테스트는 개발자가 코드를 리팩토링하거나 라이브러리 업그레이드를 할 때 기존 기능이 올바르게 작동하고 있는지 확인할 수 있다.
- 기능에 대한 불확실성을 감소시킬 수 있다.
- 시스템에 대한 실제 문서를 제공한다. 단위 테스트 자체가 작동 방식을 설명해주는 문서로 사용된다.
기존 테스트 코드를 작성하지 않는 테스트는
- 코드 작성
- 프로그램(Tomcat)을 실행한 뒤
- Postman과 같은 API테스트 도구로 HTTP 요청을 진행한 뒤
- 요청결과를 로그로 남겨 눈으로 검증
- 결과가 다르다면 다시 프로그램(Tomcat)을 내리고 코드를 수정
위와 같은 진행과정은 톰캣도 여러번 올렸다 내려야 해서 시간을 많이 잡아먹고 사람의 손으로 진행되는 과정이기 때문에 테스트에 대한 일관성과 시간이 비효율적이다.
단위 테스트 코드를 작성하므로써 얻는 점들
- 프로그램(Tomcat)을 수동으로 반복적으로 뛰우는 과정이 필요없어진다
- 사람의 눈으로 검증하는 것이 아닌 코드에 의한 자동검증이 가능해진다
- 기능들이 여러 단위로 분류되어에 각자의 단위 테스트를 가지고 있을 때 기능을 확장하거나 변경할 때 기존 기능에 대한 확실성을 준다.
테스트 코드 프레임워크
가장 대중적인 테스트 프레임워크는 xUnit이 있다.
개발환경에 따라 단위 테스트를 도와주는 도구이다.
- JUnit-java
- DBUnit-DB
- CppUnit-C++
- Nunit-.net
스프링을 통한 프로젝트를 하면 당연히 JUnit을 사용하게 되고 현재는 Junit4,Juint5가 가장 많이 사용된다.
테스트 코드 작성하기전 테스트 코드 작성할 때 알아두어야 할 class 및 Annotation을 정리해보자.
우선 프로젝트를 생성하면 프로젝트 최상단에 main 메서드를 가지는 클래스를 만들어 주어야 한다.
package com.boot.springboot;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Application {
public static void main(String[] args){
SpringApplication.run(Application.class, args);
}
}
@SpringBootApplication
스프링 부트의 자동 설정, 스프링 Bean 읽기,등록을 가능하게 해준다.
(프로젝트 최상단에 위 클래스를 위치 시키는 이유는 @SpringBootApplication의 위치부터 설정을 읽어가기 때문이다)
SpringApplication.run(Classname.class,args)
main메서드에서 실행하는 SpringApplication.run 메서드로 내장 WAS(Web Application Server)를 실행시켜준다.
내장 WAS- 애플리케이션을 실행할 때 내부에서 WAS를 실행하는 것, 톰캣의 설치가 필요없어지고 Jar파일로 바로 실행가능하다. 항상 같은 환경에서 스프링 부트를 배포할 수 있기 때문에 스프링 부트는 내장 WAS 를 권장한다.
스프링 테스트 관련 어노테이션 정리
@SpringBootTest
통합 테스트를 제공하는 기본적인 스프링 부트 테스트 어노테이션.
실제 구동되는 애플리케이션과 똑같이 application context를 로드하여 테스트하기 때문에 하고 싶은 테스트를 모두 수행할 수 있다.
모든 Bean을 올려서 테스트하기 무겁고 비효율적이라면 classes속성을 통해 원하는 class만 Bean으로 등록하게 할 수 있다.
@RunWith
JUnit 프레임워크의 테스트 실행방법을 확장할 때 사용하는 어노테이션
ApplicationContext를 만들고 관리하는 작업을 @RunWith(SpringRunner.class)에 설정된 class로 이용하겠다는 뜻이다. JUnit 4에서는 없으면 안되는 어노테이션이다.
최근 스프링 부트는 JUnit 5를 사용하기 때문에 더이상 JUnit 4에서 제공하던 @RunWith를 쓸 필요가 없고 (쓰고 싶으면 쓸 수는 있다), @ExtendWith를 사용해야 하지만, 이미 스프링 부트가 제공하는 모든 테스트용 애노테이션에 메타 애노테이션으로 적용되어 있기 때문에 @ExtendWith(SpringExtension.class)를 생략할 수 있다.
@Autowired
스프링 의존성 주입에 사용되는 어노테이션.
선언한 스프링 빈을 주입 받는다.
@WebMvcTest
MVC를 위한 테스트, 웹에서 테스트하기 힘든 컨트롤러를 테스트하는데 적합하다.
웹상에서 요청과 응답에 대한 테스트 진행시쿠리티 혹은 필터까지 자동으로 테스트하며 수동으로 추가/삭제 가능
MVC 관련된 설정인 @Controller, @ControllerAdvice, @JsonCompoent와 Filter, WebMvcConfiguer, HandlerMetohdAgumentResolver만 로드되기 때문에 @SpringBootTest 어노테이션 보다 가볍게 테스트할수 있다.
Mock과 Mockito
Mock은 단위 테스트에서 객체들의 의존성이 강해 구현하기 힘들경우 가짜 객체를 사용하는 것
Mockito는 Mock을 지원해주는 프레임워크이다.
@MockBean ,@Mock
@MockBean은 Mock과 달리 org.springframework.boot.test.mock.mockito 패키지 하위에 존재한다. spring-boot-test 에서 제공하는 어노테이션인데, Mockito의 Mock객체들을 Spring의 ApplicationContext에 넣어준다. 그리고 동일한 타입이 존재할 경우 MockBean으로 교체해준다.
Test 도중 Spring에서 어느 의존성도 필요하지 않다면, Mockito의 @Mock을 사용하면 되지만, Spring Container가 관리하는 bean들 중 하나이상을 Mocking하고 싶다면 @MockBean을 사용하면 된다.
@Transactional
Spring 에서 JPA 사용하는 어노테이션
데이터의 변경이 필요할 이루어질 때 필요한 transaction begin, commit을 자동 수행해준다.
예외를 발생시키면, rollback 처리를 자동 수행해준다.
테스트 코드 작성
Given-When-Then 패턴
테스트 코드를 작성할 때 코드를 세 부분[준비 -실행 -검증]으로 나누어 진행하는 것이다.
테스트 코드를 작성할 때 표준은 아니지만 나는 사용하고 있다.
package jpabook.jpashop.service;
import jpabook.jpashop.domain.Member;
import jpabook.jpashop.repository.MemberRepository;
import org.assertj.core.api.Assertions;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.annotation.Rollback;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.transaction.annotation.Transactional;
import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.*;
@RunWith(SpringRunner.class)
@SpringBootTest //두개가있어야 스프링부트를 올려서 테스트가능하다.
@Transactional //데이터 변경을 위해 (롤백해줌)
public class MemberServiceTest {
@Autowired MemberService memberService;
@Autowired MemberRepository memberRepository;
@Test
@Rollback(value = false)
public void 회원가입() throws Exception {
//given
Member member=new Member();
member.setName("이름");
//when
Long memberId = memberService.join(member);
//then
Assertions.assertThat(member).isEqualTo(memberService.findOne(memberId));
//영속성컨테스트에서는 PK(id)가 같으면 같은 놈으로됨
}
@Test
public void 중복_회원_예외() throws Exception {
//given
Member member1 = new Member();
Member member2 = new Member();
member1.setName("이름");
member2.setName("이름");
//when
memberService.join(member1);
//then
IllegalStateException e = assertThrows(IllegalStateException.class, () -> memberService.join(member2));
assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");
}
}
내가 직접 WAS를 만지면서 테스트하는 것이 아닌 코드를 통해 데이터를 넣고 상황을 가정하며 결과가 맞는지 확인하는 느낌이라고 생각하면 된다. 중복 회원 예외 코드를 예로 들면
given-같은 이름의 회원이 두명 주어지고
when-회원 한명은 이미 가입이 되어 있을 때
then- 두번째 회원이 가입을 하게 되면 에러가 터져야한다.그 에러메시지가 "이미 존재하는 회원입니다"가 나오면 테스트는 성공이다.
마지막 검증에서 assertThat(검증하고 싶은 대상).isEqualTo(비교대상) 메소드 체이닝 형식으로 작성했다.
두 값이 같아야 테스트가 성공한다.
테스트의 메서드명은 어떤 테스트인지 식별하기 쉽기 위해 한글로 작성해주는 것도 좋다.
assertThat 메서드는 Junit과 assertj에서 제공하는 두가지 메서드가 있는대 assertj가 더 많은 자동완성기능을 제공하고 추가적인 라이브러리를 필요로하지 않는다.
IntelliJ 에서 작성한 class의 테스트를 진행하고 싶다면 Ctrl+Shift+T 단축키로 빠르게 만들 수 있다
공부한 곳 및 출처
www.whiteship.me/springboot-no-more-runwith/
cheese10yun.github.io/spring-boot-test/
'스프링부트(SpringBoot) > 활용' 카테고리의 다른 글
Redis를 통한 랭킹보드 구현해보기 (SpringBoot+Redis) (0) | 2021.10.01 |
---|---|
Spring Security+JWT (JSON Web Token)를 통한 인증 및 권한처리 (0) | 2021.06.20 |
N+1 쿼리 문제 해결로 성능개선하기 (0) | 2021.06.07 |
Gradle 의존성 옵션 정리(Compile VS implementation,옵션) (0) | 2021.06.05 |
[스프링 부트+AWS]1. IntelliJ로 SpringBoot 시작하기 (0) | 2021.04.30 |