[TIL] 프리온보딩 세 번째 과제_RedBrick

세 번째 과제 🔥 

세 번째 과제는 레드브릭에서 내주신 과제였다.

과제 요구사항을 보면 알 수 있듯이, 이번 과제의 핵심은 실시간 반영이었다.

그리고 필요한 엔티티들도 갑자기 늘어나서 DB설계에도 많은 고민이 필요했다.

 

Git Repository

GitHub - preOnboarding-Team13/Assignment-3-redbrick: 위코드 x 원티드 프리온보딩 3번째 과제

 

Socket 통신 이용 🚉 

유저가 프로젝트를 수정할 때, 의도치 않게 사이트가 종료되어도 작업 내용이 보존되도록 수정사항이 실시간으로 반영되어야 했다.

고민 1. 실시간 통신을 어떻게 구현할 것인가? 

요구사항을 분석하면서, Socket통신이 떠오르긴 했지만, 실제로 어떻게 구현하셨는지 궁금했다.

그래서 레드브릭에서 서비스중인 위즈랩에 회원가입을 해서, 크롬 개발자 도구를 이용하여 실시간으로 어떻게 반영이 되는지 확인해보았다.

확인 결과, 편집사항이 생길 때 마다 Socket 통신을 사용하여 서버로 데이터를 전송하고 있었다. 

따라서 Socket 통신을 사용할만한 든든한 근거가 생겼기 때문에, Socket을 이용했다. 

 

이렇게 직접 사이트에서 어떤 통신들이 이루어지는지를 확인해보는 경험이 처음이라 신기했다.

 

고민 2. 어떤 '단위'로 Socket 통신을 할 것인가? 

이번 과제의 ERD

편집이 이루어질 때 마다, 변경된 부분만을 전송해서 구현하는 방법도 있었겠지만

프로젝트는 여러 개의 씬을, 씬은 여러 개의 스프라이트를, 스프라이트는 여러개의 블럭을 포함할 수 있는 꽤나 복잡한 구조였기 때문에 프로젝트 단위로 통신하는 방법을 선택했다.

@WebSocketGateway({ namespace: "project" })
export class SocketGateway {
	constructor(
		@InjectModel(Project.name) private project: Model<ProjectDocument>
	) {}

	@SubscribeMessage("update")
	handleMessage(@MessageBody() data) {
		return this.project
			.findOneAndUpdate({ projectId: data.projectId }, data, {
				returnOriginal: false
			})
			.exec();
	}

	handleDisconnect(client: Socket) {
		console.log(`Client disconnected: ${client.id}`);
	}

	handleConnection(client: Socket) {
		console.log(`Client Connected: ${client.id}`);
	}
}

 

Test Code🧪 

이번 과제를 하면서, 제대로 된 테스트 코드를 처음으로 작성해보았다.

Game Module관련 Unit Test와 E2E Test를 작성했다.

E2E Test 

Postman으로 test하던 것을, 코드로 옮긴다는 느낌이 들어서 개념을 이해하기가 쉬웠다.

물론, 실패 상황을 가정해서 test하는 것은 쉽지 않았지만 Unit Test를 작성하는 것 보다는 수월했다.

 

Unit Test 

이번 과제를 수행하면서 담당했던 부분 중에 가장 어려웠던 부분이다.

Unit Test가 뭔가? 라는 고민부터 시작해서

실제 구현할 때 mock 객체를 어떻게 만들어야 하며,, 어떤 것을 테스트 해야하는지도,, 너무 어려웠다.

 

작성한 gameService Unit Test 코드

 

비교적 테스트 코드에 경험이 있었던 효민님께 엄청나게 많은 질문폭탄을 하며 겨우 완성한 코드이다. ㅎㅎ

 

이 과제를 끝낼 때 까지 이해한 부분으로는,

Unit Test 대상이 되는 객체와 의존성이 있는 객체들을 mock 객체로 만들어 사용한다.

mock 객체는 가짜로 만든 객체를 의미한다.

 

여전히 이해하지 못한 부분으로는,

Unit Test에서 어떤 것을 테스트해야 하는가?

expect()를 사용해서 어떤 것을 검사해야하는가?

→ 실행 결과로 return될 값들을 변수로 만들어 놓고, 실행 결과와 같은지 확인하는 방식으로 진행했는데 이렇게 하는게 맞는 것인지 굉장한 의문이 들었다. 

 

너무 어렵고, 이해는 안되고, 과제 시간은 촉박하고 ㅎㅎ.. 

그래서 사실 코드를 중간정도 작성하기 전까지는 "바쁜데 굳이 이것까지 해야하나?"라는 생각이 들었다. 

하지만, 테스트 코드를 작성하면서, 내가 작성한 gameService에 예상치 못한 버그가 있다는 것을 발견했다. 

그 때 깨달았다. 이런 이유로 테스트 코드를 작성하는 것이구나!

 

그래서 앞으로 테스트 코드 관련해서 깊이 공부해봐야겠다는 생각이 들었다.

내가 테스트에 대해 너무 안일하게 생각하고 있었던 것 같다. 

 

미흡한 점이 많은 코드이지만, 테스트 코드를 완성할 수 있게 끝까지 도움을 준 효민님에게 몹시 감사하다. 

 

Maximum Call Stack Error 🙈 

계획했던 구현을 모두 마치고, 새벽에 전체적으로 테스트를 진행했다. 

그런데...!

악몽의 순간

서버에서 Maximum Call Stack Error가 발생했다.. 

실시간으로 프로젝트 수정사항을 반영할 때 발생하는 문제였는데, 과제 제출 시간이 촉박하여, 이 문제는 아직 해결되지 못했다...

하지만, Mongoose에서 컬렉션간 관계 설정을 잘못해서 발생한 것으로 추측되고 있다...

순환적으로 관계가 참조되어 있어, 타고 타고 들어가면서 call stack error가 발생한 것이 아닌가 하는..

이미 프리온보딩 코스는 끝났지만, 이 문제를 개인적으로 해결해 볼 예정이다.

 

 

소감 열마디 🤪 

Maximum Call Stack Error를 발견한 시점에는, 과제 제출을 해야하는데 에러를 이제서야 발견한 것이 너무 원망스러웠다. 하지만, 에러를 겪어야 성장할 수 있다고 하는 말처럼, 이 에러 덕분에 이런 방식으로 mongoose를 이용하면 안된다는 것을 깨달을 수 있었다. 

그래서, 지금은 이 에러를 마주한 것이 오히려 좋다! 앞으로도 에러에 절망하기 보다 배움의 기회로 삼는 긍정적인:) 개발자의 자세를 이어가려고 한다. 

 

Test Code의 중요성을 깨닫게 되었다. Test 관련 서적을 읽어볼 예정이다! 

 

2박 3일보다도 짧은 시간이지만 배우는 것이 많은 것 같아 정말 유익한 시간이다. 몸은 좀 피곤하지만..