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