1주일간의 학습 회고

테스트코드의 강의를 완강하였다.

이번 주 공부한 분량은 생각보다 많지는 않았다.

중점적으로 관심있던 부분은 TestFixture와 RestDocs였다.

TestFixture 

강의 내에서 나온 TextFixture는 많은 내용이 없었지만, 실제로 프로젝트에서 이 강의를 보기전에 적용해 본 적이 있다.

가장 도움이 되었던 내용은 토스의 기술 블로그였다. (하단 참조)

https://toss.tech/article/how-to-manage-test-dependency-in-gradle

예전에 프로젝트에서 적용하면서 느낀 장점과 단점에 대해 간단하게 기술해보면 다음과 같다.

사실 적용법은 너무 많은 블로그에 나와 있기 때문에, 개인적인 장/단점을 공유하는게 옳다고 생각한다.

장점

• Fixture관리가 편하다

• 테스트 코드에서 Fixture를 파편화 시켜서 사용하지 않아도 된다.

• Gradle에서 지원한다

단점

• Fixture도 관리 대상이 된다

  • 실제로 Entity나 DTO가 변경될 때 Fixture를 변경하지 않아서 빌드가 안되거나 하는 경우가 있었는데, 너무 번거롭다.

  • 모든 팀원들이 인지하지 않으면 꽤나 힘들다... (개인적인 생각이다)

• 깊은 연관관계가 되어 있는 경우에는 결국 여러개의 Fixture와 Fixture 시나리오를 구성해야하기 때문에 꽤나 번거롭다.

위와 같은 문제점을 해결하기 위해서, 고민을 덜기 위해 FixtureMonkey 라는 것도 고민을 해보았는데, 막상 생각보다 그렇게 와우 모먼트를 이끌만하지 않았기에 Fixture를 계속 사용하였다.

RestDocs

강사님이 이야기한것들 중에 정말 많은게 공감이 되었다.

강사님은 RestDocs, Swagger 비교를 하셨지만 거기서 더 나아가서 PostMan과 같은 상용 API 문서화 툴까지 비교를 하자면, 회사 내 우리팀은 BFF 로서 백엔드 프론트가 나뉘어져 있다.

그렇기에 API 문서화가 중요한데 API 문서화 툴의 단점은 업데이트 주기가 사람한테 맞추어져있다는 점이다.

그래서, Swagger를 도입하느냐 마느냐에 대한 이야기가 있었다.

개인적으로... Swagger를 반대하는 이유는 강의내용과 같다.

Swagger가 프로덕션 코드에 침투하는게 너무 싫다!!

그러나... RestDocs를 사용하는 이야기는 하지 않았다... 왤까?

이유는 다음과 같다.

• 아스키독스에 대한 학습이 싫다 -> 빠르게 도입을 해야할 때 발목을 잡을 수 있다

• TestCode에 대한 지식이 모든 팀원이 100%가 아니다 -> 사실 위 내용이 컸다....

좋은 방안과 툴이여도 결국 회사의 상황과 역량에 따라 어쩔 수 없지만, 개인적인 프로젝트에서는 도입을 해볼 계획이다.

해봐야 ㅋㅋ 이게 효율적인지 아닌지 알거 같다!

이번 주 학습에서 잘한 점

사내에 개선점들이 있어서 개선에 도움을 주고자 간단한 프로젝트를 자체 개발하고 있었다...

프로젝트를 하면서, 느리지만 개인적으로 한달정도를 예상하고 있어서 TDD를 통해서 그리고 읽기좋은 코드로 만들고 있다.

향후 유지보수와 문서화를 위해서 내가 공부한 내용을 적용할 수 있게 했다. 

아쉬웠던 점

금요일에!! 깜짝 세션이 있었다... 참여를 못했다!!!

같이 공부하는 팀원들과 함께 질문할것이 있었는데 ㅠㅠㅠ 하지를 못했다... 내 질문은 TDD의 영역이다...

TDD의 영역이란 테스트 커버리지 퍼센트가 아닌 실용적인 이야기다...

개인적으로 실용주의적인 개발자라 생각하여 나는 테스트코드가 100% 커버리지 혹은 90% 이상 커버리지를 좋다고 생각하지는 않는다.

그래서 TDD의 영역에 대해 물어보려 했는데ㅠㅠ....

회사 팀원들과의 협업

TDD의 영역에 대해 같이 공부하고 있는 회사 동료들에게 물어봤다! 동료 중 한 명이 강사님에게 물어보라 했는데 ㅠㅠ 까먹었다... 또한 그 동료가! 물어본 것들 중 하나가... 인터페이스의 테스트 영역에 대해서 세명이서 토론하다가 이것도 물어보자! 해서 끝났다...

좋은 동료와 좋은 스터디를 하고 이런 개념들을 발전해 나가서 너무 좋다!