테스트코드 리팩토링에 대한 논의

[20HyeonsuLee]

서론

테스트코드를 작성하다보니 몇몇 문제점들이 발견돼서 테스트 코드를 어떻게 작성해야하는지에 대한 고민을 하게 되었습니다. 이에 대해 저의 의견을 밝히고 개선하고자 하는 생각에 논의를 열어봅니다.

본론

현재 테스트코드에는 다음과 같은 문제점이 있습니다.

1. api(POST, GET, PUT, DELETE)를 하나의 클래스에 모두 작성하다 보니 가독성이 떨어진다.
2. api를 작성한 후 테스트코드를 짠다.(테스트코드를 먼저 짜는게 바람직)
3. 인수테스트의 목적과 다르게 시나리오대로 테스트되지 않는다.

위의 문제점에 대한 제가 생각한 해결책은 다음과 같습니다.

1. api의 요청 타입 별로 패키지를 나눈다.
   • shop
     ㄴ- get
     ㄴ- post
     ㄴ- delete
     ㄴ- put
2. 사용자의 api사용 시나리오에 맞게 테스트를 작성한다.
   • shop api를 예로 들면 사용자는 shop을 생성 -> 조회 -> 수정 -> 삭제한다와 같은 시나리오를 가진다.
     (shop을 생성하지 않았는데 조회할수는 없다.)
   • 따라서 테스트코드도 post -> get -> put -> delete순서로 진행되어야 한다.
   • 당연히 api작성도 post -> get -> put -> delete순서여야 한다.
3. get api를 테스트하기 위해서 shop을 repository로 save하는 것이 아니라 api요청을 통해 생성한다.

결론

점점 길어지고 관리하기 힘들어지는 테스트코드를 보며 개선할 필요가 있다고 생각했습니다.
위의 의견들은 어디까지나 저의 짧은 고민에서 나온것들이라 여러분의 의견을 공유해주세요!

[Choi-JJunho]

Good First Discussion~

우선 테스트 간결화에 대해 말씀해주신 부분에 있어 몇가지 제 생각을 이야기해봅니다

api의 요청 타입 별로 패키지를 나눈다.
좋은 의견같습니다~!
테스트를 초기화하는 beforeEach 로직이 가져야하는 관심사에 따라 구분한다는 느낌도 드는군요 👍

저는 도메인까지만 패키지를 구분하고 메소드는 클래스로 분리해도 좋을것 같다는 의견입니다!
테스트 패키지가 깊어질수록 관리가 귀찮아질거같아서 ㅎㅎ 😅

ex)

// 제안해주신 방법
test
ㄴ java
    ㄴ acceptance
        ㄴ shop
            ㄴ get
                ㄴ ActivityGetApiTest
                ㄴ ActivityPostApiTest
                ㄴ ActivityPutApiTest
...

// 저의 생각
test
ㄴ java
    ㄴ acceptance
        ㄴ shop
            ㄴ ActivityGetApiTest
            ㄴ ActivityPostApiTest
            ㄴ ActivityPutApiTest

사용자의 api사용 시나리오에 맞게 테스트를 작성한다.
get api를 테스트하기 위해서 shop을 repository로 save하는 것이 아니라 api요청을 통해 생성한다.

이 방식은 한가지 우려되는 사항이 존재합니다.
현재 /depts와 같은 API도 존재하고 모든 API가 Post를 가지지 않는다는 상황을 고려해야할 것 같습니다.
Repository로 데이터를 생성하는 방식으로 초기값을 세팅하고 검증하는 방식이 보다 안정적이라고 생각합니다.

또한 테스트끼리의 의존성이 생기면 특정 테스트가 실패했을 때 어떤 테스트 (혹은 API) 가 문제여서 테스트가 실패하는것인지 파악하기가 어렵습니다.
각각의 테스트는 독립적으로 테스트 되어야한다는 저의 입장입니다.

따라서 GET API를 테스트하기 위해서 shop을 repository로 save하는 행위는 자연스러운 일이라고 생각했습니다.

[20HyeonsuLee]

제안해주신방법이 패키지의 depth측면에서 좋아보이네요👍 저도 동의합니다.
말씀해주신 내용을 읽어보니 get api를 테스트하기 위해서 shop을 repository로 save하는것이 올바른 방법인것 같다는 생각이 드네요.
테스트코드를 어떻게 짤지에 대해서 조금 더 찾아보고 고민해봐야겠네요

[Invidam]

테스트 코드를 잘 알진 못하지만, 문서보다는 실습 영상을 보는 게 "테스트 코드 작성 흐름"을 알기가 좋더라구요

인프런에 테스트 관련 강의들도 있고

• https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EC%8B%A4%EC%A0%84-%EC%83%81%ED%92%88%EC%A3%BC%EB%AC%B8-tdd/dashboard
• https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C

왠지 모르게 https://www.inflearn.com/course/the-java-application-test 을 볼 수 있는 방법이 어딘가에 있었던 것 같아요

[Invidam]

1번 문제점 관련

가독성을 위해 클래스를 분리한다는 것이 클래스 분리 목적이 올바르진 않다는 생각이 듭니다.

가독성이 낮다면 이너 클래스, IDE의 바로가기 기능, 다음 메서드로 이동, 괄호 {...} 로 가리기 등 다양한 방법을 써볼 수 있을 것 같고
준호가 잘 알겠지만 테스트 데이터 생성 부분을 외부로 빼내는 방식 (피움에서 쓴 방식)을 채택해볼 수 있을 것 같아요

3번 해결책 관련

저는 get api를 테스트하기 위해서 shop을 repository로 save하는 것이 아니라 api요청을 통해 생성한다. 와는 다른 생각입니다.

GET API가 POST API(생성 API)에 의존하면 안된다고 생각해요.

+) 2번 해결책도 의존성 측면에서 위와 같은 생각으로 반대합니다. (2번 문제점이었던 테스트를 먼저 작성하는 게 무조건 바람직하다는 의견도 옳지 않다고 생각해요)

[20HyeonsuLee]

GET API가 POST API(생성 API)에 의존하면 안된다고 생각해요.에 대해서 동의하는 바 입니다.
사실 논의를 올리기 전에 만약 GET을 작성하기 위해 POST가 선행되어야 한다고 하면, GET자체의 테스트가 의존성을 가지기 때문에 문제점이 생길 수 있다고 생각했습니다. 하지만 테스트관점에서는 GET을 하기 위해서는 POST가 선행되어야 하지 않나?라는 생각때문에 의견을 제시했던것 같습니다. 여러가지로 고민을 더 해봐야겠네요!

[Choi-JJunho]

코드가 너무 반복되고 지저분하다고 생각이되면 Fixture를 도입해보는 방식도 고려해볼 수 있을 것 같아요
팩토리 메소드로 원하는 값을 만드는 함수 또는 정적메소드를 만들어서 재활용하는거죵

이전에 사용했던 경험으로는 영속화를 하는 Fixture를 XXSupport라고 명명하고, 영속화가 굳이 필요없는 static한 Fixture를 XXFixture 라고 정의하고 사용하기도 했습니다.
(이 방식이 정답이 아닙니다!!)

이전에 사용했던 예시로 참고할만한 코드 두고 가봅니다~

• Pium - DictionaryPlantFixture
  • Fixture 사용 예시
• Pium - DictionaryPlantSupport
  • Support 사용 예시

참고

• https://jojoldu.tistory.com/611
• https://en.wikipedia.org/wiki/Test_fixture

[songsunkook]

1. api의 요청 타입 별로 패키지를 나눈다.

목적은 좋지만 클래스별로 전부 패키지를 분리하는 것은 오히려 귀찮아질 수 있다고 생각합니다. 패키지 분리에 대한 명확한 근거가 필요할 것 같아요.

2. 사용자의 api 사용 시나리오에 맞게 테스트를 작성한다

매번 선행 작업을 전부 작성해야 하는 것이 번거로울 수 있을 것 같습니다. 1번과 같이 명확한 근거가 필요할 것 같아요.

3. get api를 테스트하기 위해서 shop을 repository로 save하는 것이 아니라 api요청을 통해 생성한다.

repository로 저장하는 것이 아니라 api를 호출하여 저장하는 것이라면 로그인 토큰이 필요하면 매번 회원가입 요청과 인증까지 수행해야 하는 건가요?? 좋은 아이디어지만 모든 곳에 적용되기는 힘들 것 같습니다.

[20HyeonsuLee]

클래스 하나에 테스트코드가 1200라인이 넘는것들이 있어서...ㅎ 뭔가 나눠야할거같긴 하다는게 저의 의견입니다.
2~3번에 관한 내용은 조금 더 고민해볼 필요가 있어보이네요

[Choi-JJunho]

우선 Fixture 형태로 개선했습니다

• test: 테스트 리팩터링 #458