[Java] TDD와 예제와 연습 , querydsl 슬라이싱 테스트 설정

🦐 TDD를 처음 접한것은 채용 공고에서였다. 우대사항에는 TDD를 쓴다는 얘기가 상당히 자주 보였다. 

최근  TDD는 죽었다라는 자동완성이 보이는 것을 보면 TDD에 대한 회의감이 드는 개발자가 많아 보인다. 

왜 유행했는 지, 비판받는 지, 궁금하니까 직접 해본다.

 

TDD ?

TDD(Test Driven Development)  소프트웨어 개발 방법 중 하나로, 테스트를 먼저 작성하고 이를 통과하기 위한 코드를 작성하는 것.

 

소프트웨어 개발 프로세스를 효율적이고 안정적으로 만들며, 품질을 높이는 데에 기여한다.

 

---

 

절차는 다음과 같다. 

 

1.테스트 작성

• 먼저 테스트 케이스를 작성한다. 이때 테스트는 실패하는 것을 기대한다.
• 테스트 케이스는 코드 작성 전에 미리 작성되며, 명확하고 간결한 요구사항을 가지고 있어야 한다.

2.코드 작성

• 테스트를 통과하기 위한 코드를 작성한다.
• 이때 작성한 코드는 테스트 케이스가 통과될 수 있도록 하는 최소한의 코드여야 한다

3.테스트 실행 및 통과 여부 확인

• 작성한 코드를 실행하여 테스트 케이스를 통과하는지 확인한다.
• 이때 테스트가 실패한다면 코드를 수정하여 다시 테스트를 실행하고, 테스트가 통과할 때까지 이를 반복한다

4.코드 리팩토링

• 테스트가 통과된 코드를 리팩토링하여 코드의 가독성, 유지보수성, 확장성 등을 개선한다.

이러한 방식으로 TDD는 소프트웨어 개발 프로세스를 더욱 안정적으로 만들어주며, 코드의 품질을 높일 수 있다. 또한, TDD는 코드 변경사항에 대한 신속한 피드백을 제공하여 버그를 미리 예방할 수 있도록 도와준다.

 

 

---

 

 

🥕 평소에 테스트 케이스 문서를 만든적이 있지만,

            유닛테스트 사용한 경험은 극히 적었다.

             TDD의 1번 부터 차례로 해보려고 헀다.

 

실패하는 테스트 케이스를 작성한다. 그리고 실패하는 것을 기대한다는 게 무슨 말인지 이해를 못했지만, 다음과 같이 작성하라는 이야기 같다.

 

1. 실패하는 케이스

컴파일도 안되고 테스트를 실행조차 할 수 없다.

 

TDD를 해본 경험이 없기 때문에 왜 이런 코드를 작성하는 지 모르겠다는 생각이 든다. 클래스부터 순서대로 컴파일이 되는 식으로 작성하고 싶은 마음이 들었다. 컴파일도 안되고 빨간줄만 뜨게끔하는 타자를 치는게 스트레스를 준다.

 

그래도, 이런 식으로, 클래스를 만들고 메소드를 만들자라고 예상하며 최대한 작성을 해본다.

 

 

2. 통과하기 위한 코드를 작성하고 

       모로 가도 서울로 가는 코드를 작성한다.

// 3만 리턴하면 테스트는 통과한다.
class Calculator {
    public int calculate(int a, int b) {
        return 3;
    }
}

 

 

 

3. 테스트 케이스를 통과하는 지 확인한다.

3리턴하면 테스트 통과하니까, 3을 리턴한다.

 

 

3. 코드를 리팩토링한다. 

         

단순히 코드만 수정하는 게 아닌 가독성, 유지보수성, 확장성 등을 개선하게끔 해야 한다.

 

 

 

 

 

 

 

---

 

연습한 것을 바탕으로 실제 게시판에 글을 쓰기 위해 연습하며 TDD를 익히려 해보았다. 

 

페이징을 위한 조회를 TDD로 연습한다면,

 

1. 실패하는 테스트 

 

2. 통과를 위한 코드를 만들고,

// PostRepositoryCustom.java

public List<PostDto> getPostsWithSearchPaging(Pageable pageable, String search) {
            List<PostDto> posts = new ArrayList<>();
        posts.add(new PostDto(10L
                ,"title"
                ,"content"
                , new UserDto("name","email","1123")
                ,null));
        return posts;
 }

 

 

3. 테스트 확인하고, 

 

4. 리팩토링한다. 

public List<PostDto> getPostsWithSearchPaging(Pageable pageable, String search) {
        BooleanBuilder booleanBuilder = new BooleanBuilder();
        if (StringUtils.hasText(search)) {
            booleanBuilder.or(qPost.postTitle.contains(search));
            booleanBuilder.or(qPost.postContent.contains(search));
            booleanBuilder.or(qPost.user.nickname.contains(search));
        }
        booleanBuilder.and(qPost.isDeleted.eq('N'));

        return queryFactory.select(Projections.fields(PostDto.class
                ,qPost.id
                ,qPost.postTitle
                ,qPost.postContent
                ,qPost.createdBy
                ,qPost.createDt
                ,qPost.recommendCount
        )).from(qPost)
            .where(booleanBuilder)
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize())
            .orderBy(qPost.createDt.desc())
            .fetch();
    }
    
   
    // TDD
    // 완성형 코드가 될 때까지 테스트하며 리팩토링.

 

개인적으로 느낀 생각은 평소 JUnit을 잘 사용하지 않았기에 Swagger-ui를 통한 테스트나 postMan을 통한 테스트를 자주 하였다.   

 

Swagger-ui를 통한 테스트 혹은 postMan을 통한 테스트보다, 여러번의 테스트를 한꺼번에 하거나, 각기 다른 테스트들을 따로따로 할 경우 시간이 많이 단축됨을 느꼈다. 

--> 물론 이는 TDD의 장점이기도 하지만,  Junit을 활용한 테스트의 장점이 더 크다고 생각한다.

 

 

 

 

TDD 방식의 단점 ? 

개발 속도가 느려진다. 

SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.

Test를 위한 코드를 작성하는 시간도 개발 시간에 포함된다. 

 

 

 

 

TDD is dead. Long live testing ?

       한참 지난 TDD 논쟁인데 이제야 안다는 것이 부끄럽다.

🔎 tdd는 죽었다: Google 검색

 

 

 

---

 

 

querydsl 슬라이싱 테스트 설정 ?

 

 

Junit 버전 : 5. xx 입니다.

 

TestClass 설정 :

 

 

TestConfig 설정 : 

 

 

 

위와 같은 설정은, 

 

Junit 에서  생성자 주입방식을 인식하지 못해서이다.

따라서 Spring에게 위임하여 Autowired를 통해 객체 의존성을 주입 받아온다. 

 

 

 

따라서, TestConfig를 통해 설정을 주입하지 않고 쓰며,  위와 같은 커스텀 Repository에서 JPAQueryFactory를 생성자 방식으로 쓸 경우, 

 

Junit Test 시에 다음과 같은 에러를 만나게 된다. 

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.org.lessortalk.post.service.PostServiceImplTest': Unsatisfied dependency expressed through field 'postRepositoryCustom'; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.org.lessortalk.post.repository.PostRepositoryCustom' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

 

 

Bean 객체를 찾지 못하므로 테스트 클래스의 모든 테스트가 실패한다면, 위 설정을 먼저 확인해보아야 한다. 

 

 

 

 

 

 

 

참고 : https://jyami.tistory.com/124

QueryDSL 슬라이싱 테스트(@DataJpaTest) / Test Bean 등록