3줄 요약
- 경계(외부API)를 어떻게 써야 효율적인지 설명한다.
- 단위 테스트를 어떤 철학을 가지고 진행하고 만들어야하는지에 대해서 설명하고 테스트는 다다익선이다.
- 테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하기에 실제 코드만큼이나 중요하다.
오늘 읽은 범위
8장 경계 ~ 9장 단위 테스트
책에서 기억하고싶은 내용
- 결국 테스트 슈트를 폐기하지 않으면 안 되는 상황에 처한다. 하지만 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다. 테스트 슈트가 없으면 시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다. 그래서 결함율이 높아지기 시작한다. 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다. 변경하면 득보다 해가 크다 생각해 더 이상 코드를 정리하지 않는다. 그러면서 코드가 망가지기 시작한다. 결국 테스트 슈트도 없고, 얼기설기 뒤섞인 코드에, 좌절한 고객과, 테스트에 쏟아 부은 노력이 허사였다는 실망감만 남는다. [156]
- 깨끗한 테스트 코드를 만드려면 가독성이 중요하다 [158]
- 깨끗한 테스트는 빠르고 독립적이고 반복가능하고 자가검증이 가능하고 적시에 작성한 코드로 이루어져야한다.[167]
읽은 소감과 떠오르는 생각
- 경계는 살짝 외부API로 치환해야 편하게 보이는듯하다. 외부 API사용할 때 어떻게 하느냐에 대한 설명으로 보이는데 학습 테스트로 검증하는 부분 공감된다.
- 경계(외부 API)에 대한 테스트 코드도 작성해놓으라는데 @_@ 띠용이다.
- 정확히 겪었던 상황이다. '테스트도 나중 가서는 대충했다. 그 때마다 끼워맞추기식 코드를 썼다. 유저들은 앱을 사용하는데 분노했고, 1년 동안의 개발이 쓰레기가 되었다.' 라는 생각으로 공감이 된다. 어떻게 해야할까? 궁금하다!!
- 159~160p를 읽으면서 테스트코드도 클린코드화 하는게 중요하다는 것을 간접적으로 느꼈다. 테스트 코드가 더러운 것에 대해서는 한 번도 생각해보지 않았었는데 생각해야겠다. 앞으로는. 160에 리팩토링했다는 코드도 깨끗하다고 와닿지는 않는다...
- HBchL뭐야 형.... 이름 잘지으라며 ㅠㅠ
- 근데 단위 테스트 케이스를 만들고 배포하기전 무조건 돌리는건 필요하다. 최소한의 안전 장치라고 생각한다.
궁금한 내용이나 잘 이해되지 않는 내용
단위테스트는 실서비스에 적용해봐야 알 것 같다......
최애의 북틸
- Daehun Gwak
https://daehun.notion.site/TIL-12-of-21-7-6bdcbc996fd54e5d8987c589372df4bc
이유: 책에 있는 내용을 그대로 옮겨적는게 아닌 사고의 흐름이 보이고 실제 업무 코드에도 적용해보시는게 멋지다
- 기선을 제압해
https://velog.io/@ttungnyang2/%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C-DAY-08
이유: 항상 쌈뽕나고 콤팩트있게 핵심만 요약해주신다. 가장 중요한 것은 본질이 맞다고 생각한다.
- Devil
https://velog.io/@asuracoder/cleancode5
이유: 난 늘 내 코드에 적용해야지 생각만 하고 그치는데 항상 Dart로 적용하시는데 대단하시다.
- topcircle
https://nomadcoders.co/community/thread/9299
이유: 늘 배우려고 하시고 열정적인 모습이 보임. 다른 분들의 TIL을 읽는데 '할 수 있다' 라는 느낌이 너무 빡들어서 글 쓰시는 것을 보는데도 나까지 용기가 남.
나 원장이 아니다