CS log

TDD 본문

Development/Backend

TDD

sj.cath 2023. 10. 5. 18:36

1. TDD 이론

  • 정의
    • 테스트 주도 개발 (Test-Driven Development)
    • 업무 코드를 작성하기 전에 테스트 코드를 먼저 만드는 것
    • 작은 단위의 테스트 케이스를 작성하고, 이를 통과하는 코드를 추가하는 단계를 반복해 구현
  • 절차
    1. 실패하는 테스트 코드 작성
    2.  테스트를 통과하는 프로그램 작성절차
      • 테스트에서 한 질문에 대한 대답   
      • 테스트를 통과하는 최소한의매우 간단한 코드로     
    3. 코드 리팩토링
      • 불필요한 것은 없애고, 모호한 것은 명확히
  • Given-when-then
    • Given: 테스트를 위해 필요한 상황 준비
    • When: 테스트하는 메서드 실행
    • Then: 테스트 결과 검증

 

2. JUnit5

  • 소개
    • 자바 개발자들이 가장 많이 사용하는 테스팅 프레임워크
    • 자바 8이상을 필요로 함
    • JUnit5 대안: TestNG, Spock 등
  • 구조
    • Platform: JVM에서 테스트 프레임워크를 실행하는데 기초 제공
    • Vintage: 하위 호환성을 위해 Junit3과 Junit4를 기반으로 돌아가는 플랫폼에 테스트엔진을 제공
    • Jupiter: 테스트를 작성하고 확장을 하기 위한 새로운 프로그래밍 모델과 확장 모델의 조합

3. JUnit5 - annotations 기본

1) @Test : test 메서드로 인식하고 테스트한다.

2) @BeforeAll : 테스트가 시작하기 전 한번 실행된다.

3) @AfterAll : 테스트가 완전히 끝난 후 한번 실행된다.

4) @BeforeEach : 각 테스트 메소드가 실행되기 전에 실행되어야 하는 메소드를 명시한다.

5) @AfterEach: @Test, @RepeatedTest, @ParameterizedTest, @TestFactory가 붙은 테스트 메소드가 실행된 후 실행

6) @Disabled : 테스트 클래스나 메소드의 테스트 비활성화

 

4. JUnit5 - annotations 테스트 이름 표시하기

1) @DisplayName : Test 결과에 나오는 테스트 class와 Method 이름을 정할 수 있는 어노테이션. 이모지도 가능!

2) @DisplayNameGeneration : @DisplayName처럼 별도의 이름을 주는 것이 아닌 코딩한 Class, Method 이름을 이용해 변형시키는 어노테이션

 

5. JUnit5 - assertion

1) 정의 : 테스트가 원하는 결과를 제대로 리턴하는지 확인할 때 사용하는 메소드

2) import org.junit.jupiter.api.Assertions.*

3) 아래 다양한 메소드~

 

6. JUnit5 - Assumption

1) 정의 : 특정 조건을 만족하는 경우에 테스트를 실행하는 방법

2) org.junit.jupiter.api.Assumptions.*

3) AssumeTrue : public static void assumeTrue(boolean assumption), Assumption 조건이 true인 경우 다음 라인의 코드 진행

4) AssumingThat : public static void assumingThat(boolean assumption, Executable executable), 조건이 true인 경우 executable의 lambda 형식의 인스턴스 실행

5) EnabledOnOs : 특정 Os에서만 테스트를 실행

6) DisabledOnOs : 특정 os에서는 테스트를 실행하지 않는다.

7) 

4. 그 밖에 TIL

 

1)@AutoConfigureTestDatabase

@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)

위 코드를 사용하면, Spring Boot는 테스트용 데이터베이스를 자동으로 구성하지 않는다.
대신, 프로덕션 데이터베이스 설정을 그대로 사용한다.
테스트에서 실제 데이터베이스를 사용하고자 할 때 유용하다.

 

 

2) 생성자

전공 수업 시간에 배웠던 생성자가 나와서 반가워 정리를 해보자면

memberId 부분에 에러가 떴다. memberId 타입이 잘못 됐다고 한 것인데, 나는 given 부분에 Long 타입으로 올바르게 했다고 생각해 이 test code에는 문제가 없다고 생각한 후 더 서치를 해보았다.

'CommentModifyRequestDto(java.lang.String)' in 'efub.session.community.comment.dto.CommentModifyRequestDto' cannot be applied to '(java.lang.Long, java.lang.String)'

 에러 메세지를 해석해보니 CommentModifyRequestDto 클래스의 생성자가 CommentModifyRequestDto(java.lang.String) 형태로 정의되어 있어서 CommentModifyRequestDto 객체를 생성할 때 Long과 String 두 개의 인자를 받는 생성자를 사용할 수 없는 상태인 것이다. 

따라서 해결 방법은 CommentModifyRequestDto의 생성자를 수정하여 Long 타입의 memberId와 String 타입의 content를 받는 형태로 변경하는 것. 

 

그런데 CommentModifyRequestDto 코드를 살펴보니 애초에 생성자 코드가 없어서.. 그냥 생성자를 새로 만들어주었다.

그랬더니 

public CommentModifyRequestDto(Long memberId, String content) {
        this.memberId = memberId;
        this.content = content;
    }

ps. comment tdd 에서는 이렇게 해서 문제가 해결되었는데, post tdd에서는 문제가 해결되지 않는다.. 도움을 요청해야겠다.

 

3) getter와 setter

private fieldName; 

//Getter
public getFieldName(){
return fieldName;
}

//Setter
public void setFieldName(fieldName){
	this.fieldName = fieldName;
}

 

'Development > Backend' 카테고리의 다른 글

Bounded Context Language  (0) 2023.11.21
DDD (Domain Driven Design)  (0) 2023.11.21
Spring Security & JWT  (1) 2023.11.04
Django part1~part4  (0) 2023.03.27