TDD

참고 동영상

https://repo.yona.io/doortts/blog/issue/1

https://howtodoinjava.com/spring-boot2/testing/spring-boot-mockmvc-example/

TDD?

Test Driven Development 의 줄인말으로, 가장 중요한 것은

테스트를 먼저 만들고, 이 테스트를 통과하기 위한 코드를 짜는 것

이런 개념이다

이러한 방식을 사용해서 잘 동작하고, 깔끔한 코드를 생성하는 것이 주 목적이다

언제사용해야하나?

• 처음해보는 프로그램 주제

• 고객의 요구조건이 바뀔 수 있는 프로젝트

• 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우

• 내가 개발하고 나서 이 코드를 누군가 유지보수할지 모르는 경우

=> 불확실성이 높을 때 사용하면 좋다!

진행방식(절차)

• Ask : 테스트 작성을 통해 시스템에 질문 - 테스트 수행 실패

• Respond : 테스트를 통과하는 코드를 작성해서 질문에 대답 - 테스트 성공

• Refine : 아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은 명확히 해서 대답을 정제 - 리팩토링

  • 소스의 가독성이 적절한가?

  • 중복된 코드는 없는가?

  • 이름이 잘못 부여된 메소드나 변수명은 없는가?

  • 구조의 개선이 필요한 부분은 없는가?

• Repeat : 다음으로 넘어가서 계속 진행

Unit Test

하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트

• 모듈 : 애플리케이션에서 작동하는 하나의 기능 또는 메소드

→ 애플리케이션을 구성하는 하나의 기능이 올바르게 동작하는지 독립적으로 테스트

단위 테스트는 원하는 부분만 독립적으로 테스트하기 때문에 빠르게 문제 여부를 확인할 수 있다.

BDD

Behavior-driven development의 약자로 행위 주도 개발이라고 해석할 수 있다. → 여기서 행위란 비지니스 요구 사항이라고 생각하면 된다

함수 단위의 테스트를 권장하지 않고, 시나리오 기반의 테스트 케이스를 작성한다

• Feature : 테스트에 대상의 기능 / 책임을 명시

• Scenario : 테스트 목적에 대한 상황을 설명

• Given : 시나리오 진행에 필요한 값을 설정

• When : 시나리오를 진행하는데 필요한 조건을 명시

• Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시

JUnit?

• 테스트 결과가 예상과 같은지를 판별해주는 단정문(assertions)

• 여러 테스트에서 공용으로 사용할 수 있는 테스트 픽스처(test fixture)

  • 테스트를 반복적으로 수행할 수 있도록 도와주고, 매번 같은 결과를 얻게 해주는 기반이 되는 상태나 환경

• 테스트 작업을 수행할 수 있게 해주는 테스트 러너(test runner)

Junit3에서는 setUp과 tearDown이라는 두 개의 테스트 픽스처 메소드를 지원한다

setUp은 테스트 메소드가 실행되기 전에 공통으로 호출되는 메소드

tearDown은 테스트 메소드가 수행되고 나서 다음으로 호출되는 메소드

test suite : 여러개의 테스트 케이스를 한꺼번에 수행하고자 할 때

Junit4부터는

@Test : 메소드의 이름과는 관계없이 이 애노테이션만 붙이면 테스트 메소드로 인식하게 된다.

• @Ignore를 사용해서 원하는 테스트 메소드를 무시하고 사용할 수 있다.

Junit3에서 사용하던 setUp과 tearDown은 @Before나 @After로 대신해서 사용

@BeforeClass, @AfterClass를 사용해서 하나의 테스트 클래스 내에서 한번만 실행하는 메소드 생성 가능

fail() 함수 : Junit에서 제공하는 메소드로, 호출되는 순간 해당 테스트 케이스는 무조건 실패 = throw new Exception

• 오류 vs 실패 : 오류는 작성자가 의도하지 않은 예상치 못한 실패를 의미하고, 이는 케이스 자체에 문제가 있음을 의미

assertEquals 함수 : 예상값과 실제값을 비교하는 조건을 만족하지 않으면 실패

• assertEquals(예상값, 실제값) 형식으로 사용

• assertArrayEquals(예상값, 실제값) 형식을 사용해서 배열을 비교하는 것도 가능

@Before : 각 테스트 케이스가 실행되기 전에 이걸로 표시해둔 메소드가 먼저 실행된다

@RunWith : 여기서 인자로 넣어준 클래스를 이용해서 클래스 내의 테스트 메소드를 수행하도록 지정해준다

• Spring에서는 SpringJUnit4ClassRunner를 인자로 자주 넣어서 사용해주는데, 지정해두면 Repeat, ProfileValueSourceConfiguration등 스프링에서 자체적으로 만들어둔 테스트 기능 사용 가능

• @SuiteClasses를 사용할 수 있는데 이건 여러 개의 테스트 클래스를 일괄적으로 수행한다. 인자를 넣어준 순서대로 순차적으로 실행

Hamcrest

Matcher 라이브러리로, 테스트 표현식을 작성할 떄 좀 더 문맥적으로 자연스럽게 만들 때 사용한다.

Matcher란 값들에 대해서 일치나 규칙준수 등을 판별하기 위해서 만들어진 메소드나 객체이다.

예시로 이 라이브러리는 assertEquals 말고 assertThat을 사용하라고 권장하는데 이건 문맥적으로도 더 알아보기 쉽기 때문이다

assertThat(테스트대상, matcher구문) / assertThat("메세지", 테스트 대상, matcher 구문)

• @Ignore를 사용해서 원하는 테스트 메소드를 무시하고 사용할 수 있다.

Mock?

모듈의 겉모양이 실제 모듈과 비슷하게 보이도록 만든 가짜 객체

기본적인 분류 개념

테스트 더블이라는 이름을 사용하는데, 이건 오리지널 객체를 사용해서 테스트를 진행하기 어려울 경우, 이를 대신해서 테스트를 진행할 수 있도록 만들어주는 객체를 의미

1. 더미 객체 : 멍청한 모조품, 단순한 껍데기를 의미하고 오로지 인스턴스화될 수 있는 수준으로만 구현한 객체 → 인스턴스화한 객체가 필요할 뿐, 해당 객체의 기능까지는 필요하지 않은 경우에 사용 - 타입 기본값((), null, false 등)으로 반환값을 만들어주는 선으로만 / 만약 호출 시에는 예외를 발생시키게 만들어둬야함

2. 테스트 스텁 : 더미 객체가 마치 실제로 동작하는 것처럼 보이게 만들어둔 객체 / 객체의 특정 상태를 가정해서 만들어둔 단순 구현체 / 특정한 값을 리턴해주거나 특정 메시지를 출력하는 등의 작업

3. 페이크 객체 : 스텁과 비슷하지만 스텁은 하나의 인스턴스를 대표하는데 주로 사용되는 것에 비해서 페이크 객체는 여러개의 인스턴스를 대표할 수 있는 경우나 좀 더 복잡한 구현이 들어가있는 객체를 지칭 → 테스트에 사용할 아이템과 카테고리에 대해서만 실제로 DB에 접속해서 비교할 때와 동일한 모습처럼 보이게 만든다. 여기서는 Map이나 List를 이용해서 DB같은 외부 의존 환경을 대체한다

4. 테스트 스파이 : 테스트 내에서 객체의 호출, 그 객체의 메소드 등 호출 여부를 몰래 감시해서 기록했다가 나중에 요청이 오면 기록 정보들을 가지고 있다가 전달해주는 역할을 하는 테스트 더블 → 사용하는 경우가 드물고, 테스트 스파이가 필요해도 Mock에서 지원을 하기 때문에 지원해주는거 사용

5. Mock 객체 : 일반적인 테스트 더블은 상태를 기반으로 테스트 케이스를 작성하는데 Mock 객체는 행위를 기반으로 테스트 케이스를 작성한다.

Mock 프레임워크

Mock 프레임워크(라이브러리)는 동적으로 Mock 객체를 만들어주는 프레임워크를 의미한다. 실행하는 메소드 생성 가능

장점

• Mock 객체를 직접 작성해서 명시적인 클래스로 만들지 않아도 된다.

• Mock 객체에 대해서 행위까지도 테스트 케이스에 포함시킬 수 있다.

예시

• EasyMock

• jMock

• Mockito

• assertArrayEquals(예상값, 실제값) 형식을 사용해서 배열을 비교하는 것도 가능

MockMvc?

웹 애플리케이션을 애플리케이션 서버에 배포하지 않고도 스프링 MVC의 동작을 재현할 수 있게 해주는 클래스

적용과정

@WebMvcTest(테스트하려는 컨트롤러이름.class)

• MVC를 위한 테스트 애노테이션이

• 웹상에서의 request, response에 대해서 테스트하는 것이 가능

• Controller, ControllerAdvice, JsonComponent, Converter, GenericConverter, 등 제한된 내용만 스캔

@RunWith : 여기서 인자로 넣어준 클래스를 이용해서 클래스 내의 테스트 메소드를 수행하도록 지정해준다

• Spring에서는 SpringJUnit4ClassRunner를 인자로 자주 넣어서 사용해주는데, 지정해두면 Repeat, ProfileValueSourceConfiguration등 스프링에서 자체적으로 만들어둔 테스트 기능 사용 가능

• @SuiteClasses를 사용할 수 있는데 이건 여러 개의 테스트 클래스를 일괄적으로 수행한다. 인자를 넣어준 순서대로 순차적으로 실행

Hamcrest

Matcher 라이브러리로, 테스트 표현식을 작성할 떄 좀 더 문맥적으로 자연스럽게 만들 때 사용한다.

Matcher란 값들에 대해서 일치나 규칙준수 등을 판별하기 위해서 만들어진 메소드나 객체이다.

예시로 이 라이브러리는 assertEquals 말고 assertThat을 사용하라고 권장하는데 이건 문맥적으로도 더 알아보기 쉽기 때문이다

assertThat의 사용방법

assertThat(테스트대상, matcher구문) / assertThat("메세지", 테스트 대상, matcher 구문)

Mock?

모듈의 겉모양이 실제 모듈과 비슷하게 보이도록 만든 가짜 객체

기본적인 분류 개념

테스트 더블이라는 이름을 사용하는데, 이건 오리지널 객체를 사용해서 테스트를 진행하기 어려울 경우, 이를 대신해서 테스트를 진행할 수 있도록 만들어주는 객체를 의미

1. 더미 객체 : 멍청한 모조품, 단순한 껍데기를 의미하고 오로지 인스턴스화될 수 있는 수준으로만 구현한 객체 → 인스턴스화한 객체가 필요할 뿐, 해당 객체의 기능까지는 필요하지 않은 경우에 사용 - 타입 기본값((), null, false 등)으로 반환값을 만들어주는 선으로만 / 만약 호출 시에는 예외를 발생시키게 만들어둬야함

2. 테스트 스텁 : 더미 객체가 마치 실제로 동작하는 것처럼 보이게 만들어둔 객체 / 객체의 특정 상태를 가정해서 만들어둔 단순 구현체 / 특정한 값을 리턴해주거나 특정 메시지를 출력하는 등의 작업

3. 페이크 객체 : 스텁과 비슷하지만 스텁은 하나의 인스턴스를 대표하는데 주로 사용되는 것에 비해서 페이크 객체는 여러개의 인스턴스를 대표할 수 있는 경우나 좀 더 복잡한 구현이 들어가있는 객체를 지칭 → 테스트에 사용할 아이템과 카테고리에 대해서만 실제로 DB에 접속해서 비교할 때와 동일한 모습처럼 보이게 만든다. 여기서는 Map이나 List를 이용해서 DB같은 외부 의존 환경을 대체한다

4. 테스트 스파이 : 테스트 내에서 객체의 호출, 그 객체의 메소드 등 호출 여부를 몰래 감시해서 기록했다가 나중에 요청이 오면 기록 정보들을 가지고 있다가 전달해주는 역할을 하는 테스트 더블 → 사용하는 경우가 드물고, 테스트 스파이가 필요해도 Mock에서 지원을 하기 때문에 지원해주는거 사용

5. Mock 객체 : 일반적인 테스트 더블은 상태를 기반으로 테스트 케이스를 작성하는데 Mock 객체는 행위를 기반으로 테스트 케이스를 작성한다.

Mock 프레임워크

Mock 프레임워크(라이브러리)는 동적으로 Mock 객체를 만들어주는 프레임워크를 의미한다.

이것은 WebApplicationContext를 로드하여 내장된 서블릿 컨테이너가 아닌 Mock 서블릿을 제공

장점

• Mock 객체를 직접 작성해서 명시적인 클래스로 만들지 않아도 된다.

• Mock 객체에 대해서 행위까지도 테스트 케이스에 포함시킬 수 있다.

예시

• EasyMock

• jMock

• Mockito

MockMvc?

웹 애플리케이션을 애플리케이션 서버에 배포하지 않고도 스프링 MVC의 동작을 재현할 수 있게 해주는 클래스

적용과정

@WebMvcTest(테스트하려는 컨트롤러이름.class)

• MVC를 위한 테스트 애노테이션이

• 웹상에서의 request, response에 대해서 테스트하는 것이 가능

• Controller, ControllerAdvice, JsonComponent, Converter, GenericConverter, 등 제한된 내용만 스캔

@AutoConfigureMockMvc 를 사용하면 별다른 설정 없이 MockMvc를 사용한 테스트를 진행할 수 있다.

실습

@SpringBootTest

이 애노테이션은 통합 테스트를 제공하는 기본적인 스프링부트 테스트 애노테이션이다.

스프링 부트는 이 애노테이션을 통해서 테스트에 필요한 거의 모든 의존성을 제공

@AutoConfigureMockMvc

MockMvc사용

Service나 Repository를 가급적이면 빈으로 주입받아서 사용하지 말자! - 특수한 경우가 아니면 쓰지마!

@ControllerAdvice

@Valid

get

• 모든 객체를 가져오는 getAllStaff 테스트

  • 더미데이터를 어떻게 넣어두고 가져올까 고민했는데 → 그냥 만드는 코드를 복붙해서 사용

• getAllStaff를 호출시, 만약에 db안에 값이 아무것도 없을 때의 테스트

  • 204-no content로 보내줌

• 하나의 객체를 가져오는 getStaff 테스트

• 없는 값을 가져와달라는 경우의 테스트

  • 만약 없는 값을 요청했을 경우에는 원래는 RuntimeException을 일으키도록 되어있었는데

  • 없는 값을 요청할시, 컨트롤러에 가져온값이 없을테니 여기서 없는 값일 때 400-bad request으로 떨구라고 내부코드수정

post

• id값을 제외하고 인자들을 채워넣어주면 그 인자들을 사용해서 객체를 저장하는 saveStaff 테스트

• 이미 존재하는 id로 post 전송하는 경우의 테스트

  • 만약 이미 존재하고 있는 id값을 넣어주고 새로운 인자들을 넣어주면 현재는 수정해서 넣어주는데, 불가능하도록! - UPDATE와 기능이 겹친다

  • service에서 만약 받은 값의 id에 해당하는 객체가 이미 있다면 400-bad request리턴

put

• 이미 존재하고 있는 객체에 대해서 수정하는 테스트 - 모든 인자값을 넣어줘야함

• 인자들 중에 하나라도 없을 경우(id, name, position)의 테스트 → @Valid나 @ControllerAdvice를 통해서 널값을 처리하려고 했지만, PUT에 한정해서만 처리하고 싶어서 담에 필요할 때 사용

  • 컨트롤러에서 받을 떄, 만약에 인자중에 빠진게 있다면 바로 400-bad request으로 리턴

• 인자들은 다 들어왔는데, 만약 존재하지 않는 id값에 대한 테스트

  • 서비스에서 404-not found로 리턴

patch

• 수정하는 테스트 - 존재하는 id값에 대해서 수정하고 싶은 인자를 넣어줘야함

• 존재하지 않는 id에 대해서 수정하는 경우의 테스트

  • 서비스에서 404-not found로 리턴

• 기존 객체에 존재하지 않는 인자를 받았을 경우의 테스트

  • 받아온 값들이 null일 경우에 400-bad request로 리턴

delete

• 원하는 id에 대해서 삭제하는 경우의 테스트

• 존재하지 않은 id에 대해서 삭제하는 경우의 테스트

  • 없지만 성공 204-no content