부트캠프 71, 72일차 (GraphQL, TDD)
오늘의 생각
이틀간 GraphQL과 TDD, 그리고 이를 활용한 과제를 페어 분과 함께 진행했다.
TDD는 그래도 리액트를 통해 하는거라 그나마 할만했지만, GraphQL은 새로운 라이브러리의 활용이라 쉽지 않았다.
개인적으로 REST API와 GraphQL의 가장 큰 차이점은 쿼리를 통해 Explorer를 쓸 수 있다는 점 아닐까...싶다
repository(owner: "codestates-seb", name: "agora-states-fe")
GraphQL을 활용하면서 가장 어려웠던 점은 "내가 사용하는 쿼리의 문법을 맞게 적었는가?" 였다. 이러한 부분을 물리적으로 확인하기가 어려웠기 때문인데, 쿼리의 기본 틀에 알맞은 owner와 name을 입력하면 Explorer에서 알려주는 걸 몰랐다. 알게 된 뒤 오열
TDD는 OOP만큼 익숙한 주제이고, Java에서 J-Unit Test와 즐거운(?) 추억이 있었기 때문에 그 중요성에 대해서도 잘 알고 있었다.
하기 어려운 개발 방식이지만, 그만큼 좋은 개발 방식이라고 생각했다.
확실히 페어 과제를 진행했을 때 "무엇을 위한 테스트인가"를 생각한 후 "테스트를 통과하기 위한 코드는 무엇인가"라는 생각으로 넘어가자 논리 구조에서 헤매는 과정이 드라마틱하게 줄은 것 같았다.
알고 있지만 잘 못쓰는...하지만 그만큼 더 잘 쓰고 싶은 개발 방식임에는 틀림없는 것 같다.
오늘의 키워드
GraphQL, 스키마Schema, 쿼리Query, 엔티티, REST API, Overfetch, Underfetch, playground, 리졸버Resolver, Mutation, Subscription, TDD(Test-driven Development), describe, it, asser, expect, Testing library, Jest
오늘의 학습내용
- GraphQL의 정의 및 특징
- REST API의 한계, GraphQL과의 차이점
- GraphQL의 장단점
- GraphQL 키워드 별 정의 및 활용법
- TDD의 정의 및 개발주기, TDD를 사용하는 이유
- TDD 테스트 코드를 작성하는 방법 (React 포함)
어려웠던 keyword / 활용한 질문
Q. GraphQL이 왜 자료구조로 Graph를 선택했나요?
A. 클라이언트 요청에 따라 유연하게 자원을 가져오기 위해서입니다. GraphQL에서는 모든 데이터가 그래프 형태로 연결되어 있다고 전제 클라이언트 요청에 따라 유연하게 트리 구조의 JSON 데이터를 응답으로 전송할 수 있습니다.
Q. 왜 TDD를 써야 하나요?
A. 예상하지 못했던 버그를 줄여 소요 시간을 줄일 수 있기 때문입니다. 코드를 작성하기에 앞서 테스트 코드를 먼저 작성해야 되기 때문에 그렇지 못한 과정에서 중복되는 요소가 생기는 등의 일을 높은 확률로 방지할 수 있습니다. 단, TDD의 개발주기에 따라 테스트 코드 작성 후 중복 코드를 제거하고, 일반화 등의 리팩토링을 수행해야 합니다.