코드숨 3주 차 회고

🔥 글의 목적: 코드숨 3주 차 학습을 기록한다. 이번 주에 무엇을 배웠는지 반성할 것은 무엇인지 기록하고자 한다.

📌 학습 내용

• TDD를 위한 기본적인 환경설정 방법
• TDD와 BDD 방법론
• React-Testing-Library
• Jest

2주 차 과제였던 간단한 todo 만들기의 테스트 코드를 작성해 보는 시간을 가졌다. 살면서 처음 써보는 테스트 코드에 무엇을 어디서부터 시작해야 할지 사실 잘 감을 잡지 못한 시간이었다.

과제를 수행하면서 힘들었던 점은 테스트 코드를 처음 사용하다 보니 “이 컴포넌트에서 어디까지 테스트를 해야 하는 거지?”, “태그의 className 들도 잘 사용했는지 테스트해야 하나?“와 같은 물음들이었다.

📌 회고

TDD라는 것을 들어는 보았지만 실제로 이것을 해보는 것에는 많은 어려움과 두려움이 있었다. 사실 아직 실력이 턱도 없이 부족한데 “내가 TDD까지 할 수 있을까?”라는 생각이 많았던 것 같다. 하지만 이번 기회에 TDD를 직접 해보기 위해 자료도 찾아보고 코드도 작성해 보니 이런 두려움이 많이 사라졌다.

그리고 뒤늦게 깨달은 것은 BDD 개발 방식의 의미에 있었다. 이번 주 내내 A 컴포넌트에 있는 모든 것을 테스팅 해야 한다고 생각하고 있었다. BDD 방식에 관한 글들도 읽었지만 잘 이해하지 못하고 있었고 TDD를 하는 근본적인 이유에 대해서 잘못 이해하고 있었다. 기존의 구현 주도 테스트 방식으로만 생각을 해서 이번 TDD를 하면서도 js-dom을 이용해 모든 값을 테스트하려 했었고 test.js에서 구현 주도 방식으로 테스팅을 하려고만 하여 과제를 제대로 해내지 못했다. 중간중간 Jest와 testing-llibrary에서는 왜 id나 className을 가지고 Jest-dom을 검색하는 방법은 만들지 않았을까 의문을 가지기도 했었다.

아직 많은 부분들을 명확하게 이해하지는 못한 상태이다. 그러나 직접 테스트 코드를 구현해보고 자료들을 보면서 여러가지 생각을 해볼 수 있었다. 개발자는 무언가를 만들 때 많은 케이스들을 생각하면서 코드를 만들게 된다. 그리고 이럴때 수많은 케이스를 한 번에 생각하면서 코드를 짜는 것은 쉽지 않은 일이다. 분명 아까는 생각하고 있었는데 이를 금방 잊어버리기도 할 것이다. 그럴 때 이렇게 테스트 코드를 미리 작성하여 수많은 케이스들을 미리 작성하고 이를 하나씩 해결해가며 코드를 작성하는 방법이 시간이 없다고 바로 코드를 작성하는 것보다 효율적이고오류를 줄일 수 있는 좋은 코드를 만들 수 있는 방법이라 생각하게 된 한 주였다.