올해 초부터 이 과정이 있다는 사실은 알고 있었지만 여러가지 내가 가진 자원들의 제약들로 인해 이제서야 수강할 수 있게 되었다.
지인분이 추천해주셔서 너무너무 궁금했는데 입사한 후에 듣는 것보다 지금 취업 준비를 할 때 듣는 것이 시간적으로도 여유롭고, JavaScript에 대해서 충분히 고민해본 경험이 나중에 업무를 할 때도 강점이 될 수 있지 않을까? 하는 생각으로 고민 끝에 수강신청을 했다.
아래는 간략한 수업 내용 + 수업 도중 내가 했던 질문과 답변을 정리했다.
TDD
TDD에 대한 사고방식
- 피드백을 마지막에 받는게 아니라 내 결정이 제대로 동작하는지 빠르게 피드백 받기 위함이다.
- 결정과 피드백 사이의 갭을 조절!!
TDD는 언제하는 것이 좋은가?
- 여러번 해봐서 어떻게 해야할지 아는 경우 굳이 필요 X
- 처음 해봐서 막연한 경우....😥
- 요구사항이 바뀔 수 있는 경우
- 개발 중에 코드가 많이 변경될 거 같은 경우
- 내가 개발하고 누가 유지보수할 지 모르는 경우
TDD를 하는 과정
- 구현하고 싶은 기능 생각해보기
- 테스트하는 방법에 대해 생각해보기
- 작은 테스트를 작성하면서 원하는 api를 생각해보기
- 테스트에 실패할 만큼만 코드를 작성하기
- 실행하고 테스트가 실패하는지 확인
- 테스트를 통과할 만큼의 코드만 작성
- 실행하고 모든 테스트가 통과하는지 확인
(이 때 통과하지 못하면 뭔가 잘못한 것인데, 방금 작성한 부분을 수정) - 중복이 있는 경우 제거하고 재사용성을 높이기 위해 리팩토링
(여기에는 결합도 감소 및 및 응집도 증가가 포함) - 테스트를 다시 실행하면 여전히 모든 테스트가 통과해야한다.
(통과하지 못한다면 수정하고 다시 실행) - 새 코드를 작성하는 테스트를 더 이상 찾을 수 없을 때까지 위의 단계를 반복
강의 도중에
Q. 테스트코드를 작성하고 기능을 구현하는 것과 기능을 먼저 구현하고 테스트코드를 후에 작성하는 것에 어떤 차이점이 있을까? 왜 테스트코드를 먼저 작성하라고 하는 것일까?
궁금해서 여쭤봤다 🙋♀️
나말고도 같은 의문을 가지는 사람들이 있을 것 같아 아래에 답변을 공유한다.
A. 테스트코드를 먼저 짜야 테스트를 통과하기 위한 최소한의 코드 작성 범주가 명확해진다.
구현코드를 먼저 작성하면 '이것도 좀 고쳐야겠는데...? 이것도 조금 넣어야겠는데...?'
이렇게 최소한의 코드에서 벗어나면서 피드백을 받는데 까지의 시간이 더 걸릴 가능성이 높다.
테스트코드 작성하고 기능 작성하고 테스트받고 리팩토링하고 테스트받고.... 의 반복되는 과정속에 빠르게 피드백을 받아서 더 확신을 가진 상태로 코드를 작성하기 위함이다.
TDD에 관심이 있어서 예전에 따로 강의를 들어보긴 했는데 테스트코드 작성에 대한 강의들이라 크게 테스트코드의 효능(?)을 체감하지 못했는데, 1주차 과제를 하면서 굉장히 편리하다고 느꼈다.
특히 지금처럼 내가 나를 못 믿을 때 (위의 TDD를 언제하면 좋은가?의 2번째 이유와 같다),
너무 간만에 바닐라 JS로 무언가를 구현하는 중이라 리팩토링하면서 코드를 조금만 손봐도 '요구사항이 다 정상적으로 작동하려나...? 🙄' 하고 의문이 들 때, 테스트코드는 이미 요구사항들이 동작하는지 테스트해주고 있다.
클린 코드
코드를 클리닝 하는 과정에 집중하자!
의도를 드러내는 네이밍
- 의도를 드러내고
- 구현은 숨기고
- 반환 타입에 대한 명확한 힌트 제공
과제를 구현하면서 의도를 드러내는 네이밍을 해보려고...... 노력해봤는데
내가 작성한 코드는 객관적으로 보기가 참 힘든 것 같다 (내가 썼으니까 내가 보기엔 잘 읽힌다....ㅎㅎ....)
이래서 코드 리뷰가 필요하구나 라고 다시 한번 느꼈다! 😮💡✨
