# 프론트엔드 테스팅과 설계 세미나 참석 후기 ## 세 줄 요약 세미나 후기 * 테스트에 대한 새로운 관점이 생겨났다. * Q&A가 매우 유익해서 좋았다. * 테스팅을 위한 소프트웨어 설계에 대한 추가 발표나 컨텐츠가 기대된다. ## 세미나 정경 * **처음 들어갔을 때 보인 풍경.** 사람이 너무 많아서 긴장했습니다. ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1710994234199/aa2e4e51-a0cb-414f-927d-ee8b42ef0bb3.jpeg align="center") * **발표 직전 정경** ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1710994256221/f1486efb-4599-41e1-8313-09a9418c4207.jpeg align="center") * 구름이 이렇게 큰 회사가 된 줄 몰랐는데 대단하다고 느꼈습니다. ## 세미나 노트 * 테스트 관련 내용으로 책을 집필 중이라고 하셔서 기대됩니다. 발표 내용 자체는 예전에 소개해주셨던 글의 내용에서 크게 벗어나지 않았습니다. * 연사인 재엽님은 이번 발표가 4번째 비슷한 내용으로 발표중이라고 언급하셨습니다. * 주제 발표는 30분정도, 나머지 거의 50분을 Q&A 시간으로 들었습니다. * 테스트를 하는 것이 좋은 엔지니어링일까? * 정의 - 무엇 * 이유 - 왜 * 대상 - 무엇 * 전략 - 어떻게 * 전술 - 언제 * 이 다섯가지 분류 순서대로 간단하게 발표가 진행됐습니다. #### 정의 - What * 기본 분류 * 단위 * 통합 * 인수 * 분류1 * 기능 * 비기능 * 분류2 * 명세 기반 (블랙 박스) * 구조 기반 (화이트 박스) * 분류3 * 작은 * 중간 * 큰 * 분류를 최종 분류한 기준 * 개발에 도움 * 비용대비 이익이 크고 * 지속가능해야함 * 최종 분류 * 기능 * 명세 * 단위 * 작은 #### 이유 - Why 1. 변화하는 코드에 대응 2. shift left: 오류를 빠르게 발견하기 위해(소프트웨어 개발 주기에서 왼쪽으로 이동) 3. 더 나은 설계를 위해 - 자신의 코드를 자신이 사용하는 경험이 필요 1. 확장 가능성, 인터페이스, 코드나 모듈의 의도를 생각하게 됨 2. 리팩토링 가능한 코드 3. 웹 접근성 고려 가능 4. 문서화와 커뮤니케이션 1. 초기에는 문제가 없는데 결국 뒤로 갈수록 커뮤니케이션 비용이 커진다 2. 그걸 대신하는게 테스팅, 문서보다 훨씬 믿을만하다 #### 대상 - What * 기능에 대한 테스트가 전부 * 분류 * 기능 = 책임 * 구현 = 세부사항(드러나지 않아야 하는 것) * 카운터 예시 * 기능: 버튼을 누르면 숫자가 늘어난다. * 구현: state를 통해 숫자가 관리된다. #### 전략 - How * **테스팅에 대한 오해들** 1. 테스트의 목적은 버그의 박멸이다 * 테스트를 작성하기 위해 제품에는 변경이 생기면 안된다 * 구현을 테스트하기 위한 변경은 X * 테스트 코드만을 위한 변경 X * 기능을 테스트하기 위해서 O 2. 테스트하기 좋은 코드가 좋은 코드다 3. 테스트 커버리지는 의미가 없다 * 동기부여나 단기 목표로 삼기 좋다 4. 테스트 코드는 없는것보다 낫다 * 오히려 방해될 수 있다. 때로는 없는게 낫다 * **테스트는 왜 어려울까?** * 환경이 다르다. 브라우저 환경 <-> Node.js 환경 * 외부와의 상호작용 * 상태: UI 메모리, runtime, browser 등등 * 이런식의 프론트 어플리케이션의 의존성 때문에 어렵다 * **해결책: 경계를 나누자** * **외부 의존성** * Browser storage 인프라 * DOM * Javascript * Router * React * **의존성 관리 전략** * Mocking -> DI로 바꾸자 * 의존성을 식별하새 어떻게 관리할지 정한다 #### 전술 - When * 엔지니어링 -> shift front * 소프트웨어 개발보다 앞 단계에서 대응하자 * 애초에 설계가 테스트에 친화적으로 코드를 짜자 * 나중에 테스트가 필요하면 추가하자 * **테스트가 어려운 진짜 이유 -> 중요하다고 생각하지 않기 때문** * 제가 들은 내용대로 간략하게 요약을 하긴 했지만 더 상세한 내용들은 재엽님의 글에 있습니다. * [프론트엔드 테스트 코드와 의존성](https://www.jbee.io/articles/developments/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C%20%ED%85%8C%EC%8A%A4%ED%8A%B8%20%EC%BD%94%EB%93%9C%EC%99%80%20%EC%9D%98%EC%A1%B4%EC%84%B1) * [테스트에 대한 오해와 사실](https://www.jbee.io/articles/developments/%ED%85%8C%EC%8A%A4%ED%8A%B8%EC%97%90%20%EB%8C%80%ED%95%9C%20%EC%98%A4%ED%95%B4%EC%99%80%20%EC%82%AC%EC%8B%A4) * (사실.. 자리가 조금 불편해서 노트를 적기 너무 힘들었습니다) ## Q&A 세미나에서 인상깊었던 점 정리 * 쓰고 버릴 기능은 테스트 비중을 낮게 유지하자. (토스도 제품 반복 주기가 빠른 제품은 테스트를 거의 작성하지 않는다고 합니다) * e2e 테스트는 시간 비용이나 여러가지로 비용이 과다하기 때문에 서비스 개발자가 직접 하기에는 안좋아 보인다. 전문가들에게 맡기면 좋겠다. * 설계 단계에서 코드의 레이어를 나누자. * 컴포넌트 테스트는 통합 테스트의 영역에 해당된다. 통합 위주로 짠다. * 훅 테스트는 컴포넌트 테스트에 포함되어 테스트하기 떄문에 따로 테스트하지 않는다.(제가 마음대로 재정리해서 틀릴 수 있습니다) * ❓호모지니어스 페트로 지니어스 테스트? 라는 용어로 참여자 한 분이 질문을 주셨는데 내용이 이해가 안돼서 찾아봤습니다. * 호모니지어스(Homogeneous) 테스트: '동종의', '동일한 성질을 가진'이라는 의미의 테스트. 비슷한 유형의 컴포넌트나 시스템간에 진행되는 테스트. 예를 들어, 동일한 환경을 가진 여러 인스턴스에 대한 테스트가 있습니다. * 헤테로지니어스(Heterogeneous) 테스트: '이종의', '서로 다른 성질을 가진' 이라는 의미의 테스트. 예를 들어, 서로 다른 의존성의 데이터베이스를 가진 기능에 대한 테스트가 있습니다. * 테스트를 많이 쓰면 결국 입력과 출력 검증을 하게 되고 외부 의존성을 고민하게 된다.(이 내용도 제가 의역을 많이 했습니다) * 유즈 케이스를 작성하는 시간이 매우 길고 이걸 기반으로 테스트를 작성 -> 코드를 작성하는 순서로 작업 중이다. * 테스트 코드 자체에 대한 리뷰와 인터페이스에 대한 리뷰가 더 길다. 모듈 간 협력도 얘기를 많이 한다. * [앨리스터 코오번의 유스케이스](https://product.kyobobook.co.kr/detail/S000001469859) 추천 (번역이 조금 난해 하다는 의견을 들었습니다) * [레거시 코드 활용 전략](https://product.kyobobook.co.kr/detail/S000001804724) 추천 : 시스템 설계 참고용 ## 세미나 다 듣고 든 감상 1. 테스트 코드에 대해서 더 많이 실천해봐야겠다. 2. 코드 레이어를 나누는 설계가 결국 프론트에도 필요하겠다. 리액트는 골치가 아프겠다. 3. 레거시 코드 활용 전략, 유즈 케이스 책 읽고 싶다. 4. 리액트에서 레이어 어떻게 나눴는지 궁금하다. * 이것 관련해서는 궁금증을 해소시켜주는 재엽님의 토스 아티클이 있습니다. [링크](https://toss.tech/article/restructuring) ## 마치며 세미나 참석 정리글은 처음 해봐서, 여러모로 가독성이 떨어지는 글이 되었네요. 다음에는 다른 분들의 후기글도 참고해서 미리미리 잘 준비된 글을 작성해보겠습니다. 이번 세미나 참석을 통해서 관점이 달라진 부분도 있고, 특히 e2e 테스트의 필요성에 대해서 다시 한번 돌이켜 생각해 볼 수 있던 좋은 기회였습니다.