반응형
해당 글에서는 Spring Boot 환경에서 JUnit에 대해 이해하고 환경을 구성하는 방법에 대해 알아봅니다.
💡 [참고] 이전에 작성한 Test 관련 글들을 읽으시면 도움이 됩니다.
분류 | 링크 |
JUnit 5 이론 및 구성 요소 | https://adjh54.tistory.com/341 |
JUnit 5 환경구성 및 활용예제 | https://adjh54.tistory.com/342 |
JUnit 5 + Mockito 이론 및 활용예제 | https://adjh54.tistory.com/346 |
JUnit 5 + MockMvc 이론 및 활용예제 | https://adjh54.tistory.com/347 |
Assertions API Document | https://adjh54.tistory.com/348 |
개발방법론 TDD, BDD | https://adjh54.tistory.com/305 |
JUnit 5 + Mockito + MockMVC 사용예제 Github | https://github.com/adjh54ir/blog-codes/tree/main/spring-boot-test |
1) JUnit5
💡 JUnit5
- Java 언어에서 독립된 단위 테스트(Unit Test)를 지원해 주는 프레임워크를 의미합니다.
- JUnit 5의 경우 'Java8 이상 버전'부터 지원을 하며 JUnit Platform, Jupiter, Vintage 모듈이 결합된 형태를 가지고 있습니다.
[ 더 알아보기 ]
💡 단위 테스트(Unit Test)
- 소프트웨어 개발에서 개별적인 코드 단위를 테스트하는 것을 의미합니다.
- 코드의 작은 부분을 격리시켜 독립적으로 테스트함으로써 코드의 정확성과 신뢰성을 검증합니다.
- 자동화가 되고 반복 가능하며 버그를 빠르게 찾아내고 수정하는데 도움이 됩니다. 또한 코드 변경 시 기존 기능에 영향을 주지 않고 코드의 동작을 확인하는 데 유용합니다.
💡 단위 테스트의 범위
- 클래스, 메서드, 함수와 같은 작은 단위의 코드를 격리시켜 독립적으로 테스트하는 것을 의미합니다.
- 따라서, 컨트롤러단이나 서비스단과 같은 구성 요소는 각각 개별적인 단위로 테스트될 수 있습니다.
2) JUnit5 구성요소
💡 jUnit5 구성요소
- JUnit5에서는 Platform, TestEngine Interface, TestEngine, Jupiter, Vintage으로 구성이 되어 있습니다.
구성 요소 | 설명 |
JUnit Platform | - JUnit 테스트를 실행하는데 사용되는 실행환경입니다. - 이는 다양한 TestEngine 구현체를 실행하고 테스트 결과를 보고하는 역할을 수행합니다. |
TestEngine Interface | - JUnit Platform에서 테스트 엔진을 정의하는 데 사용됩니다. - 이 인터페이스를 구현하여 사용자 정의 테스트 엔진을 만들 수 있습니다. |
TestEngine | - JUnit Platform에서 테스트를 실행하는 데 사용되는 구현체입니다. - 각각의 TestEngine은 특정한 테스트 프레임워크 또는 런처와 통합되어 동작하며, 테스트 수명주기 관리, 테스트 실행, 결과 보고 등의 기능을 제공합니다. |
JUnit Jupiter | - JUnit 5에서 제공되는 새로운 프레임워크입니다. - 이는 테스트 작성과 실행을 위한 새로운 기능과 어노테이션을 제공하며, JUnit 4보다 더 강력하고 유연한 테스트 코드 작성이 가능합니다. |
JUnit Vintage | - JUnit 4와의 하위 호환성을 제공하기 위한 모듈입니다. - 이 모듈은 JUnit 4로 작성된 테스트를 JUnit 5 플랫폼에서 실행할 수 있게 해줍니다. |
1. JUnit Platform
💡 JUnit Platform
- JUnit 테스트를 실행하는 데 사용되는 실행 환경을 의미합니다. TestEngine Interface를 통하여 다른 TestEngine 구현체들과 상호작용하여 테스트를 실행하고 테스트 결과를 보고하는 역할을 수행하는 테스트 프레임워크입니다.
- 테스트의 수행 과정은 발견, 실행, 결과 보고의 과정을 통해서 수행이 됩니다.
💡 JUnit Platform의 주요 특징
1. JUnit Platform에서 TestEngine Interface를 통해 테스트 엔진(Jupiter, Vintage)과 상호작용을 합니다.
- 테스트 엔진과의 통신을 통해 테스트 수명주기 관리, 동적 테스트 검색 및 실행, 테스트 결과 보고 등을 지원합니다.
2. JUnit 3, 4, 5와 같은 테스트 프레임워크를 지원합니다.
- JUnit 5와의 호환성을 제공하며, JUnit 4로 작성된 테스트를 JUnit 5 플랫폼에서도 실행할 수 있도록 하는 모듈을 포함하고 있습니다.
3. 다양한 환경 및 설정에서 테스트를 실행할 수 있습니다.
- 테스트 실행을 위한 표준화된 인터페이스를 제공하여 다양한 테스트 프레임워크와 런처가 통합될 수 있도록 합니다. 이를 통해 개발자는 자신이 선호하는 테스트 프레임워크를 사용하여 테스트를 작성하고, JUnit Platform에서 실행할 수 있습니다.
[ 더 알아보기 ]
💡Test Framework와 TestEngine의 차이는?
- 테스트 프레임워크는 테스트를 작성하고 실행하기 위한 구조와 규칙을 제공하며 TestEngine은 테스트를 실행하는 엔진으로 테스트를 ‘실제 실행하고 결과를 반환하는 역할’을 담당합니다.
2. TestEngine Interface
💡 TestEngine Interface
- JUnit Platform에서 테스트를 실행하고 결과를 보고하는 데 사용이 되는 인터페이스로 TestEngine에 대한 메서드와 속성을 정의하는 데 사용이 됩니다.
- TestEngine Interface를 기반으로 TestEngine의 구현체를 구성합니다. 이를 통해 사용자 정의 TestEngine을 만들 수 있습니다.
💡 [참고] TestEngine Interface의 주요 메서드
메서드 | 리턴 타입 | 설명 |
discover() | void | - 테스트를 발견하고 고유한 ID를 부여하는 메서드입니다. |
execute() | void | - 테스트를 실행하는 메서드입니다. |
getId() | String | - 테스트 엔진의 고유 식별자를 반환하는 메서드입니다. |
getGroupId() | String | - 테스트 엔진의 그룹 식별자를 반환하는 메서드입니다. |
getVersion() | String | - 테스트 엔진의 버전을 반환하는 메서드입니다. |
3. TestEngine
💡 TestEngine
- TestEngine Interface의 구현체로 테스트를 실행하는 데 사용이 됩니다.
- 각각 TestEngine은 특정한 테스트 프레임워크 또는 런처와 통합되어 동작하며, 테스트 수명주기 관리, 테스트 실행, 결과 보고 등의 기능을 제공합니다.
4. JUnit Jupiter
💡 JUnit Jupiter
- JUnit 5에서 제공되는 새로운 프레임워크를 의미하며 테스트 작성과 실행을 위한 기능을 어노테이션을 제공하며 JUnit4 보다 강력하고 유연한 테스트 코드를 작성하도록 제공해 줍니다.
💡 [참고] JUnit Jupiter의 주요 어노테이션
- 3) 주요 어노테이션 & 메서드 부분에서 상세하게 알아봅니다.
어노테이션 | 설명 |
@Test | 테스트 메서드를 정의하는 데 사용되는 어노테이션입니다. 이 어노테이션이 지정된 메서드는 JUnit Jupiter에서 테스트로 실행됩니다. |
@ParameterizedTest | 매개변수화된 테스트를 정의하는 데 사용되는 어노테이션입니다. 이 어노테이션이 지정된 메서드는 여러 매개변수를 사용하여 반복적으로 실행됩니다. |
@BeforeEach | 각각의 테스트 메서드가 실행되기 전에 실행되는 코드를 정의하는 데 사용되는 어노테이션입니다. |
@AfterEach | 각각의 테스트 메서드가 실행된 후에 실행되는 코드를 정의하는 데 사용되는 어노테이션입니다. |
5. JUnit Vintage
💡 JUnit Vintage
- JUnit 3, 4의 TestEngine을 JUnit 5 플랫폼에서 사용할 수 있도록 제공을 합니다.
- JUnit 5 플랫폼을 사용하여 JUnit 4 테스트를 실행할 수 있으며, JUnit 5의 다양한 기능과 호환성을 유지할 수 있습니다. 또한 기존의 테스트 코드를 유지하면서도 JUnit 5의 새로운 기능과 개선점을 활용할 수 있습니다.
6. 구성 요소 별 전반적인 흐름
💡 구성 요소 별 전반적인 흐름
1. 사용자는 IDE Tool을 이용하여 테스트 코드를 실행합니다.
2. 테스트 코드는 JUnit Platform 내에서 수행이 됩니다.
3. 테스트 코드를 구성하는 메서드나 어노테이션에 대해서는 TestEngine Interface를 이용하여 호출하여 구성합니다.
4. TestEngine Interface의 실제 구현되는 구현체는 Junit Jupiter, Junit Vintage, Custom Engine을 기반으로 구현이 됩니다.
3) JUnit 5 주요 어노테이션 & 메서드
1. JUnit 5 어노테이션
💡JUnit 5 어노테이션
- JUnit Jupiter에서는 테스트 구성 및 프레임워크 확장을 위해 다음 어노테이션들을 지원합니다.
어노테이션 | 설명 |
@Test | 테스트 메소드임을 나타내는 어노테이션 |
@ParameterizedTest | 매개변수화된 테스트를 위한 어노테이션 |
@RepeatedTest | 반복적으로 실행되는 테스트를 위한 어노테이션 |
@TestFactory | 동적으로 테스트를 생성하는 팩토리 메소드를 정의하는 어노테이션 |
@TestTemplate | 테스트 템플릿을 정의하는 어노테이션 |
@TestClassOrder | 테스트 클래스의 실행 순서를 지정하는 어노테이션 |
@TestMethodOrder | 테스트 메소드의 실행 순서를 지정하는 어노테이션 |
@TestInstance | 테스트 인스턴스의 생명주기를 지정하는 어노테이션 |
@DisplayName | 테스트의 표시 이름을 설정하는 어노테이션 |
@DisplayNameGeneration | 테스트의 표시 이름을 동적으로 생성하는 어노테이션 |
@BeforeEach | 각 테스트 메소드 실행 전에 실행되는 메소드를 정의하는 어노테이션 |
@AfterEach | 각 테스트 메소드 실행 후에 실행되는 메소드를 정의하는 어노테이션 |
@BeforeAll | 모든 테스트 메소드 실행 전에 실행되는 메소드를 정의하는 어노테이션 |
@AfterAll | 모든 테스트 메소드 실행 후에 실행되는 메소드를 정의하는 어노테이션 |
@Nested | 중첩된 테스트 클래스를 정의하는 어노테이션 |
@Tag | 테스트를 그룹화하기 위한 태그를 지정하는 어노테이션 |
@Disabled | 비활성화된 테스트를 나타내는 어노테이션 |
@Timeout | 테스트의 제한 시간을 설정하는 어노테이션 |
@ExtendWith | 커스텀 확장을 적용하는 어노테이션 |
@RegisterExtension | 커스텀 확장을 등록하는 어노테이션 |
@TempDir | 테스트용 임시 디렉터리를 생성하는 어노테이션 |
2. JUnit 5 Assertions 메서드
💡 JUnit Assertions
- 단위 테스트에서 다양한 유형의 검사를 수행하기 위한 일련의 Assertions 메서드를 제공합니다. 이러한 어서션은 테스트되는 코드의 예상 동작을 확인하는 데 도움이 됩니다.
- 모두 import org.junit.jupiter.api.Assertions 패키지를 임포트 하여서 사용합니다.
메서드 | 구분 | 설명 |
assertEquals(expected, actual) | JUnit 4~ | 예상값과 실제값이 동일한지 확인합니다. |
assertArrayEquals(expected, actual) | JUnit 4~ | 예상 배열과 실제 배열이 동일한지 확인합니다. |
assertNull(object) | JUnit 4~ | 객체가 null인지 확인합니다. |
assertNotNull(object) | JUnit 4~ | 객체가 null이 아닌지 확인합니다. |
assertSame(expected, actual) | JUnit 4~ | 예상값과 실제값이 같은 객체인지 확인합니다. |
assertNotSame(expected, actual) | JUnit 4~ | 예상값과 실제값이 다른 객체인지 확인합니다. |
assertTrue(condition) | JUnit 4~ | 조건이 참인지 확인합니다. |
assertFalse(condition) | JUnit 4~ | 조건이 거짓인지 확인합니다. |
assertAll((Executable... executables) | JUnit 5 | 모든 단언문(assertion)이 성공하는지 확인합니다. |
assertIterableEquals(Iterable<?> expected, Iterable<?> actual) | JUnit 5 | 예상 가능한 순서로 반복 가능한 항목이 동일한지 확인합니다. |
assertLinesMatch((List<String> expectedLines, List<String> actualLines) | JUnit 5 | 두 문자열 목록이 일치하는지 확인합니다. |
assertNotEquals(Object unexpected, Object actual) | JUnit 5 | 예상값과 실제값이 동일하지 않은지 확인합니다. |
assertThrows(Class<T> expectedType, Executable executable) | JUnit 5 | 지정된 예외가 발생하는지 확인합니다. |
assertTimeout(Duration timeout, Executable executable) | JUnit 5 | 주어진 시간 내에 작업이 완료되는지 확인합니다. |
assertTimeoutPreemptively(Duration timeout, Executable executable) | JUnit 5 | 주어진 시간 내에 작업이 완료되는지 확인하며, 작업이 중단될 수 있습니다. |
💡 [참고] Assertion 메서드를 활용한 기본 예시에 대해 궁금하시면 아래의 코드를 확인하시면 도움이 됩니다.
4) JUnit 5 활용방안
1. JUnit 라이프 사이클
💡 JUnit 라이프 사이클
- JUnit을 구성한 클래스를 구성으로 @Test가 수행되는 기준으로 전후에 수행되는 라이프 사이클에 대해서 알아봅니다.
단계 | 설명 |
Setup | 각 테스트 메서드가 실행되기 전에 필요한 설정 작업을 수행합니다. |
Test | 실제 테스트가 진행되는 주요 단계입니다. 각 테스트 메서드는 개별적으로 실행되며, 코드의 예상 동작을 확인하기 위해 어설션(assertion) 또는 검증(verification)이 수행됩니다. |
Cleanup | 각 테스트 메서드가 실행된 후 필요한 정리 작업을 수행합니다. |
Suite-level setup and cleanup | 테스트 스위트의 모든 테스트 메서드 실행 전후에 한 번씩 발생합니다. 테스트 스위트 전체에 적용되어야 하는 설정 또는 정리 작업을 수행하는 데 사용됩니다. |
💡 JUnit 라이프 사이클 수행과정
* 기본적으로 위에서 아래로 @Test를 선언한 순서에 따라 수행이 됩니다.
1. [@BeforeAll] JUnit 클래스가 수행되면 최초 한번 @BeforeAll 어노테이션을 선언한 메서드가 실행이 됩니다.
2. [@BeforeEach] @Test을 찾았다면 테스트 실행 전 @BeforeEach을 선언한 메서드가 실행됩니다.
3. [@Test] @Test를 선언한 메서드가 실행됩니다.
4. [@AfterEach] @Test 실행을 마치면 @AfterEach를 선언한 메서드가 실행됩니다.
5. @Test를 선언한 메서드가 있는지 찾으며 존재하면 (2. 과정)을 반복수행하며, 존재하지 않는 경우 (6. 과정)을 수행합니다.
6. [@AfterAll] 실행할 @Test가 존재하지 않는다면 @AfterAll을 선언한 메서드를 수행합니다.
7. 테스트를 종료합니다.
2. AAA(Arrange - Act - Assert) 패턴
💡 AAA(Arrange - Act - Assert) 패턴
- Arrange(준비), Act(실행), Assert(검증)의 약자로, 테스트 코드를 구조화하는 데 유용한 패턴입니다.
단계 | 설명 |
Arrange (준비) | 테스트에 필요한 객체나 데이터를 설정하는 단계로 테스트하려는 객체를 생성하고 모든 의존성을 준비합니다. |
Act (실행) | 준비된 객체나 데이터를 사용하여 실제로 테스트하려는 동작을 실행하는 단계입니다. |
Assert (검증) | 실행 결과가 예상한 대로인지 확인하는 단계. JUnit의 assert 메서드를 사용하여 결과를 검증합니다. |
@SpringBootTest
class MyServiceTest {
@Autowired
private MyService myService;
@Test
void testCalculate() {
// Arrange
int input = 5;
// Act
int result = myService.calculate(input);
// Assert
assertEquals(10, result);
}
}
3. Given-when-then 패턴
💡 Given-when-then 패턴
- 테스트 케이스를 더 가독성 있고 유지보수하기 쉽게 구조화하는 방법을 의미합니다.
- 이 패턴을 따르면 테스트 케이스가 더 구체적이고 이해하기 쉬워지며 각각의 단계를 분리하여 각 테스트 부분이 어떤 역할을 담당하는지 명확해집니다.
섹션 | 설명 |
Given : 설정 | 테스트의 초기 상태 또는 사전 조건을 설정합니다. 입력 데이터나 테스트가 실행될 문맥을 지정합니다. |
When : 동작 | 테스트되는 동작 또는 이벤트를 설명합니다. 테스트되는 특정 메서드나 동작을 나타냅니다. |
Then : 검증 | "When" 섹션에서 설명한 동작으로 인해 기대되는 결과 또는 동작을 정의합니다. |
💡 Given-when-then 패턴을 이용한 예시
- Given 섹션에서는 '초기 상태'를 설정하고 When 섹션에서는 '특정 동작을 수행'하며, Then 섹션에서는 '예상 결과를 검증'하는 어서션(assertion)을 사용하여 검증합니다.
import org.junit.jupiter.api.Test;
import java.util.ArrayList;
import static org.junit.jupiter.api.Assertions.*;
class MyTest {
@Test
void testListSize() {
// Given
ArrayList<String> list = new ArrayList<>();
// When
list.add("Apple");
list.add("Banana");
list.add("Orange");
// Then
assertEquals(3, list.size());
assertTrue(list.contains("Apple"));
assertFalse(list.isEmpty());
}
}
[ 더 알아보기 ]
💡 AAA 패턴이랑 Given-When-Then 패턴은 결국 똑같은거 아닌가?
- 맞습니다. 모두 테스트 코드를 구조화하는 데 사용되는 패턴으로, 매우 유사합니다. 각각의 단계는 다음과 같이 대응됩니다:
1. Arrange (준비) = Given (주어진 상황)
- 테스트에 필요한 객체나 데이터를 설정하는 단계입니다.
2. Act (실행) = When (실행할 동작)
- 준비된 객체나 데이터를 사용하여 실제로 테스트하려는 동작을 실행하는 단계입니다.
3. Assert (검증) = Then (예상 결과)
- 실행 결과가 예상한 대로인지 확인하는 단계입니다.
💡 [참고] 해당 패턴은 BDD의 테스트 시나리오를 작성하는 단계에서도 동일하게 적용이 됩니다.
4. JUnit 명명 규칙
💡 인기 있는 JUnit 명명 규칙
- JUnit의 메서드명을 지정하는 명명 규칙에 대해 알아봅니다.
- 이를 통해서 어떤 테스트를 수행하는지 명시적으로 이해할 수 있도록 돕습니다.
- 아래의 글을 참고하여서 작성하였습니다.
4.1. 명명 규칙 -1 : '메서드명_테스트대상상태_예상동작' 형식
💡 MethodName_StateUnderTest_ExpectedBehavior
- '메소드명_테스트대상상태_예상동작' 형식으로 JUnit 메서드 명을 지정하는 방식입니다.
- 이 전략에 대해서는 메소드 이름이 코드 리팩토링의 일부로 변경된다면 이 테스트 이름도 변경되어 나중에 이해하기 어려워진다는 반대 의견이 있습니다.
[ 사용 예시 ]
- isAdult_AgeLessThan18_False : 만약 나이가 18보다 작으면 성인이 아님 (False)을 반환하는 경우
- withdrawMoney_InvalidAccount_ExceptionThrown : 잘못된 계정으로 출금 시 예외가 발생하는 경우
- admitStudent_MissingMandatoryFields_FailToAdmit: 필수 입력 필드가 누락되었을 때 학생을 입학시키지 못하는 경우
4.2. 명명 규칙 -2 : '메서드명_예상동작_테스트대상상태 '형식
💡 MethodName_ExpectedBehavior_StateUnderTest
- “메서드명_예상동작_테스트대상상태” 형식으로 JUnit 메서드 명을 지정하는 방식입니다.
- 조금 다른 방식으로 변경된 것이지만, 일부 개발자들은 이 명명 기법을 사용하는 것을 권장합니다. 이 기법은 메서드 이름이 변경되면 이해하기 어려워진다는 단점도 있습니다.
[사용 예시]
- isAdult_False_AgeLessThan18: 만약 나이가 18보다 작으면 성인이 아님 (False)을 반환하는 경우
- withdrawMoney_ThrowsException_IfAccountIsInvalid: 잘못된 계정으로 출금 시 예외가 발생하는 경우
- admitStudent_FailToAdmit_IfMandatoryFieldsAreMissing: 필수 입력 필드가 누락되었을 때 학생을 입학시키지 못하는 경우
4.3. 명명 규칙 -3: “test” 접두어 형식
💡 test [Feature being tested]
- “test” 접두어 형식으로 JUnit 메서드 명을 지정하는 방식입니다.
- "test" 접두어가 중복된다는 주장도 있지만, 일부 개발자들은 이 기법을 사용하는 것을 선호합니다. 또한 SonarLint에 code smells를 피할 수 있다는 이유로 권장됩니다.
[사용 예시]
- testIsNotAnAdultIfAgeLessThan18: 만약 나이가 18보다 작으면 성인이 아님을 테스트합니다.
- testFailToWithdrawMoneyIfAccountIsInvalid: 잘못된 계정으로 출금 시 실패하는 것을 테스트합니다.
- testStudentIsNotAdmittedIfMandatoryFieldsAreMissing: 필수 입력 필드가 누락되었을 때 학생이 입학되지 않는 것을 테스트합니다.
4.4. 명명 규칙-4 : 테스트할 기능 형식
💡 Feature to be tested
- 일부는 메서드를 테스트 메서드로 식별하기 위해 이미 주석을 사용하고 있으므로, 단순히 테스트할 기능을 작성하는 것이 더 좋다고 제안합니다.
- 이는 단위 테스트를 문서의 대체 형태로 만들어주고 SonarLint에 code smells를 피할 수 있다는 이유로 권장됩니다.
4.5. 명명 규칙 -5: Should_예상동작_테스트대상상태 형식
💡 Should_ExpectedBehavior_When_StateUnderTest
- 'Should_예상동작_When_테스트대상상태'로 JUnit 메서드 명을 지정하는 방식입니다.
[사용예시]
- Should_ThrowException_When_AgeLessThan18: 만약 나이가 18보다 작으면 예외를 던져야 합니다.
- Should_FailToWithdrawMoney_ForInvalidAccount: 잘못된 계정일 경우 출금에 실패해야 합니다.
- Should_FailToAdmit_IfMandatoryFieldsAreMissing: 필수 입력 필드가 누락되었을 때 입학에 실패해야 합니다.
4.6. 명명 규칙 -6: When_테스트대상상태_Expect_예상동작 형식
💡 When_StateUnderTest_Expect_ExpectedBehavior
- 'When_테스트대상상태_Expect_예상동작'으로 JUnit 메서드 명을 지정하는 방식입니다.
[사용예시]
- When_AgeLessThan18_Expect_isAdultAsFalse: 만약 나이가 18보다 작으면 성인이 아님 (False)을 예상합니다.
- When_InvalidAccount_Expect_WithdrawMoneyToFail: 잘못된 계정으로 출금 시 실패할 것을 예상합니다.
- When_MandatoryFieldsAreMissing_Expect_StudentAdmissionToFail: 필수 입력 필드가 누락되었을 때 학생 입학이 실패할 것을 예상합니다.
4.7. 명명 규칙 -7: Given-When-Then 형식
💡 Given_Preconditions_When_StateUnderTest_Then_ExpectedBehavior
- Behavior-Driven Development (BDD)의 일부로 개발된 명명 규칙입니다. 테스트를 사전 조건 (Given), 테스트 대상 상태 (When), 예상 동작 (Then)으로 세 가지 부분으로 나누어 작성합니다.
- 이 접근 방식은 Behavior-Driven Development (BDD)의 일부로 개발된 명명 규칙에 기반을 두고 있습니다. 개별 테스트를 세 부분으로 나눠 사전 조건, 테스트 대상 상태 및 예상 동작을 위의 형식에 맞춰 작성합니다.
[사용예시]
- Given_UserIsAuthenticated_When_InvalidAccountNumberIsUsedToWithdrawMoney_Then_TransactionsWillFail: 사용자가 인증된 상태에서 잘못된 계정 번호를 사용하여 금액을 인출하면 거래가 실패할 것입니다.
💡 [참고] 해당 글은 다음 글에서 예시로 수행되는 방법에 대해 알아봅니다.
오늘도 감사합니다. 😀
반응형
'Java > Testing' 카테고리의 다른 글
[Java] Spring Boot JUnit5 이해하기 -3: @RepeatedTest, @ParameterizedTest를 이용한 반복 테스트 (0) | 2024.07.28 |
---|---|
[Java] Spring Boot MockMvc 이해하기 : 테스트 흐름 및 사용예제 (0) | 2023.12.15 |
[Java] Spring Boot Mockito 이해하기 : 테스트 흐름 및 사용예시 (0) | 2023.12.14 |
[Java] Spring Boot JUnit5 이해하기 -2 : 환경구성 및 활용 예제 (0) | 2023.12.08 |