Cypress logic/#108

[seonghunYang]

📌 작업 내용

• 계층 분리, 기존 2 layer(component -> business)에서 3 layer(component -> business -> store)로 변경
• cypress를 통한 E2E 테스트 작성
• mock 로직 일부 수정

🤔 고민 했던 부분

• react-query와 fetch 두 가지 방식으로 같은 데이터에 접근할 경우, 데이터 동기화 문제가 발생할 수 있다고 판단됩니다. 그러므로, 아키텍처 수준에서 결정하여 하나의 데이터는 하나의 접근 방식만을 허용하도록 강제해야 합니다.
• 원칙적으로 react-query는 store 계층에 위치하고, hook 계층을 거쳐 컴포넌트에서 사용해야 합니다. 그러나 현재 react-query를 사용하는 대부분은 로직 없이 데이터만 조회하므로, hook을 만드는 것이 불필요하다고 판단했습니다. 따라서, 이는 아키텍처적으로 계층 간 지름길을 허용하는 유일한 경우입니다.
• react-query의 useSuspenseQuery와 nextJs가 호환되지 않는 문제가 발생했습니다. 이 문제는 추후에 처리가 필요합니다.(관련: Nextjs Streaming+Server Action Error: Server Functions cannot be called during initial render.  TanStack/query#6591)

🔊 도움이 필요한 부분

• 팀원들의 의견이 꼭 필요한 부분을 작성해주세요.
• 팀원들은 놓치지 않고 꼭 이 항목을 보고 의견을 주세요.
• 먼저 계층을 나눈 후, 각 도메인별로 테스트 서버와의 연동 작업을 진행해야 합니다. 이때, 아래의 방법으로 API 하나당 진행해야 하는 작업을 반복합니다:

1. 테스트 서버의 응답 값과 response type을 일치시킵니다.
2. 타입스크립트 컴파일을 실행합니다.
3. 문제가 발생한 부분을 수정합니다. 이때 mock 계층도 수정해야 합니다(만약 mock 계층이 response 타입에 의존하지 않는다면 문제가 발생하지 않을 것, 따라서 mock 계층은 response 타입에 의존하도록 만들어야함, 변경 시 mock 계층에서도 일반적으로 문제가 발생하므로 문제가 발생하지 않는다면 mock이 response 타입에 의존하지 않는지 확인하면서 작업해야 합니다).
4. jest나 storybook 테스트를 실행하거나, 테스트가 부족한 경우 수동으로 테스트를 진행합니다(테스트의 중요성을 깨닫게 해주는 기회).
5. 문제가 없다면 연동이 완료

[github-actions]

🚀storybook: https://65ccb85d5afe55a024495bc0-woblsrgziw.chromatic.com/

[gahyuun]

고생 많으셨습니다! 추가로 service의 command와 business 폴더 내부 hook의 차이점에 대해서 다시 한번만 말씀해주실 수 있나요?

[gahyuun]

if(!lecture} return false 로 처리해주기 때문에 ? 를 붙이지 않아도 될 것 같습니다!

[seonghunYang]

e8b3083

[gahyuun]

이 함수가 provider에서 어떻게 필요한지 알 수 있을까요?

[seonghunYang]

• 이 부분은 Cypress에서 애플리케이션 작업 모델 패턴을 사용하기 위해 참조를 등록하는 과정입니다. 전역 객체에 참조를 연결해두면 Cypress 코드에서 사용할 수 있습니다. 이 내용은 E2E 테스트에 대한 배경지식이 조금 필요로 한데, 제가 지금 관련 포스팅을 작성하고 있어서 작성이 완료되면 공유하도록 하겠습니다.
• Cypress 코드에서는 아래처럼 사용하면 됩니다.
  cy.window().invoke( // name of the method 'addTakenLecture', testLectureIds, );

[gahyuun]

cypress provider에서 사용중이더라구요! provider 함수 내부에서 mockDatabase.reset()을 직접 호출할 수도 있을 것 같은데, 따로 handler를 구현하신 이유가 있을까요??

[seonghunYang]

• 지금 우리 구조는 mocking을 위해 express로 전용 목 서버를 운영하고 있습니다. 이는 RSC에서도 mocking을 사용하기 위해 이렇게 구성되었습니다. 그러므로, mockDatabase 관련 코드가 같은 폴더 구조에 위치하고 있어 코드를 공유한다고 생각할 수 있지만, express 서버가 메모리에서 사용하는 데이터와 next가 메모리에서 사용하는 데이터는 서로 분리되어 있습니다. 그래서 mockDatabase.reset()를 호출해도 express 서버의 데이터는 초기화되지 않습니다.

[gahyuun]

result 도메인 리팩토링 하면서 type 파일을 따로 분리해도 좋을 것 같네요

[seonghunYang]

저는 파일을 이동하며 타입을 확인하는 것이 불편하다고 느껴 분리가 필요하다고 생각하기 전까지는 파일을 분리하는 것을 선호하지 않습니다. 혹시 타입 파일을 분리하는 것을 선호하시는 이유가 있을까요?

[gahyuun]

저는 query 함수를 찾기 위해 result 파일을 열었는데 여러 type들이 나열되어있을 때 원하는 함수를 찾는게 불편하다고 느껴서 말씀드렸습니다! 분리가 필요하다고 생각하기 전까지는 파일을 분리하는 것을 선호하지 않다고 말씀하셨는데 저는 지금이 분리가 필요한 시점이 아닐까? 라고 생각을 했습니다.
하지만 제가 개발을 하면서 직접 느낀 불편함이 아니기에 당장은 파일 분리를 할 필요가 없을 수 있겠네요

[gahyuun]

별개로 궁금한 점이 생겼습니다!
저희는 현재 폴더 분리나 파일 분리에 대해 관리하는데 불편함이 생기면 그때 그때 분리하면서 진행하고 있습니다
하지만 개개인마다 분리가 필요하다고 느끼는 시점이 다르기 때문에 여러 명이 작업을 할때, 일관성이나 통일성이 깨질 수 있다는 단점이 있지 않을까 싶은데 이에 대해서 혹시 어떻게 생각하시나요??

[seonghunYang]

• 조금 더 고민해 보고 답변드리고 싶은데, 괜찮을까요? 괜찮으면 다음 스프린트 때 논의해 봐도 좋을 듯 해요. 좋은 주제인 것 같아요.

[gahyuun]

넵!

[gahyuun]

해당 deleteLecture은 test를 위한 함수라고 느껴져서 여기에 있는게 더 적합할 것 같습니다!

[seonghunYang]

• 주석을 제거하지 않았네요. 의견 감사합니다! 여기서 고민한 부분은 Cypress 폴더의 support 폴더를 살펴보면, Cypress 코드에서 사용가능한 사용자 정의 커맨드를 정의할 수 있습니다. deleteLecture가 반복되어 이를 커맨드로 분리하여 관리하는 것을 고려했습니다. 하지만, 현재 이 테스트 외에 사용되는 부분이 없으므로, 다른 테스트에서 삭제가 필요할 경우에만 커맨드로 분리하도록 하겠습니다.

[seonghunYang]

고생 많으셨습니다! 추가로 service의 command와 business 폴더 내부 hook의 차이점에 대해서 다시 한번만 말씀해주실 수 있나요?

Hook은 클라이언트에서 상태를 조작하는 로직을 처리하는 것이며, Command는 서버 액션으로, 서버에 상태 변경 요청을 하는 것으로 구분할 수 있습니다. 데이터가 어디에 위치 하느냐에 따라 분리되는 것으로 이해하면 됩니다.

[github-actions]

🚀storybook: https://65ccb85d5afe55a024495bc0-yvagrnkfha.chromatic.com/

[yougyung]

수고 많으셨습니다 !

[yougyung]

TakenLectrueInfoResponse와 동일한데 별도로 타입 생성하신 이유가 있을까요?

[seonghunYang]

아주아주 좋은 포인트입니다. 언급해줘서 고마워요. 이유는 개념을 명확하게 구분하기 위해서입니다. TakenLectureInfoResponse 타입과 TakenLectureInfo 타입은 '지금은' 같은 타입을 가지고 있는 것처럼 보이지만, 실제로는 개념적으로 다른 타입입니다. TakenLectureInfoResponse는 서버에서 받은 응답 값의 타입을 나타내고, TakenLectureInfo는 클라이언트에서 사용하는 수강 과목 정보의 타입을 나타냅니다.

현재 두 타입은 같지만, 서버 응답 값인 TakenLectureInfoResponse는 언제든 변경될 수 있습니다. TakenLectureInfo를 따로 정의하지 않고 TakenLectureInfoResponse를 사용한다면, 현재 TakenLectureInfo를 사용하는 모든 컴포넌트를 수정해야 할 것입니다. 하지만 두 타입을 분리해두면, TakenLectureInfoResponse가 변경되더라도 TakenLectureInfo는 유지하면서 '변환 함수'나 변환 객체를 만들어 TakenLectureInfo 타입을 계속 유지할 수 있습니다. 이렇게 하면 컴포넌트를 변경할 필요가 없습니다.

이는 컴포넌트와 서버 간의 결합을 분리하는 방법입니다. 컴포넌트는 서버가 변경되는 것에 대해 알 필요가 없습니다. 단지 렌더링에 필요한 데이터만 있으면 됩니다. 그러나 알다시피 서버는 렌더링과 관련된 이유 외에도 여러 가지 이유로 변경됩니다. 이러한 변경으로부터 컴포넌트의 변경을 보호할 수 있습니다.

또한, 타입스크립트는 구조적 타이핑 언어이므로, 현재 사용하는 데 아무런 문제가 없습니다. 만약 서버에서 변경이 생겨 TakenLectureInfoResponse를 수정하게 되면, 타입스크립트에서 컴파일 에러가 발생할 것입니다. 그때 변환 함수나 객체를 이용해 변환할지, 아니면 TakenLectureInfo를 수정할지 결정하면 됩니다.

[yougyung]

친절한 설명 감사합니다. 이전에 설명해주셨던 TakenLectureInfoResponse과 TakenLectureInfo를 분리하자고 제안주셨던 의견과 같은 맥락을 공유하고 있는 것 같네요. TakenLectureInfoResponse는 언제나 변경될 수 있고, 서버의 변경에 대한 위험을 감수하지 않기 위해서 TakenLectureInfo를 분리하는 것에 대해서는 좋은 해결방안이라고 생각합니다.

다만 궁금한 점은, 현재에는 완전히 동일한 타입을 갖고있으며 근 시일내에 별도로 변경이 예상되지 않음에도 불구하고 별도로 타입을 만드셨다는 부분입니다. 같은 논리에 의하면 서버에서 response를 받고 있는 모든 타입에 대해서도 서버와 클라이언트의 컴포넌트 사이의 타입 분리를 진행해야합니다.

그래서 저희는

1. 가능성을 목적으로 현재 상태에서 모든 서버 타입과 클라이언트의 컴포넌트 사이의 타입을 분리하는 방법
2. 변경을 진행하거나 근시일내에 가능성이 존재하는 경우에 한해서만 변경을 진행 방법

둘 중에 하나를 선택하는 것이 좋아보인다는 생각이 들었습니다. 혹시 지금 시점에 타입을 분리하신 이유가 있으시다면 더 듣고 싶습니다!

[seonghunYang]

의견 고맙습니다. 3가지를 말씀드리고 싶습니다. 먼저, 서버에서 받는 모든 응답 타입과 클라이언트 컴포넌트 간의 타입 분리를 진행할 필요가 없다고 생각합니다. 이는 TakenLectureInfo와 다른 응답이 명확하게 구분되기 때문입니다. TakenLectureInfo는 use-taken-lecture 훅에서 처럼 클라이언트에서 상태를 관리하는 반면, 다른 응답은 단순히 받아서 전달하는 쿼리의 역할을 하고 있습니다. 즉 둘은 개념적으로 다릅니다.

두 번째로, 저는 근 시일 내에 별도의 변경이 예상되지 않는다는 점에는 동의하지 않습니다. 마이그레이션 작업 도중에도 API 명세 변경이 발생했고, 이런 상황은 예측 가능한 것이 아닌, 작업을 진행하면서 또는 서버측 사정으로 발생합니다. 따라서 근 시일 내에 변경 가능성을 예측하는 것은 불가능하며, 현실적으로 가능한 기준이 아니라고 생각합니다.

마지막으로, TakenLectureInfoResponse와 TakenLectureInfo를 분리하는 것은 기능적인 분리 외에도 개념적 구분을 통해 가독성을 높이는데 도움이 된다고 생각합니다. TakenLectureInfo는 클라이언트에서 상태를 관리하고 있기 때문에, 이 점이 응답과는 확실히 구분됩니다. 따라서 변경이 발생하지 않더라도 이렇게 타입을 표기하는 것이 더 좋다고 생각합니다. 그리고 저는 이게 자바나 다른 명시적 타입 언어와 다르게 자바스크립트와 같은 덕 타이핑 언어만의 장점이라고 생각합니다.

[yougyung]

먼저 말씀 드린 근 시일 내에 별도의 변경을 예상한다는 것은 변경이 필요하다고 요구되는 것을 느낀 시점을 의미하는 것이었습니다. 착오가 생길 수 있게 전달해드린점 죄송합니다. 관련 작업이 필요할 때 진행하자와 동일한 맥락에서 드린 말씀입니다 !

더불어 제시해주신 TakenLectureInfo는 클라이언트에서 상태를 관리하고 있기 때문에, 이 점이 응답과 다르다는 차원에서 생각하면 서버 측 응답과 완전히 동일하지않네요. 관련 의견에 동의합니다. 긴 글 작성해서 의견 남겨주셔서 감사합니다.