2024-07-24 퇴근길 밋업
내맘대로 되지 않는 테스트코드, 꼭 작성해야 할까? 희망편 - 김명일 님
1. 테스트 코드 왜 작성해야 할까?
테스트의 목적 : 지속적인 성장과 품질 개선
서비스가 커질때마다 비용이 커짐.
-> 테스트 자동화를 통해 비용절감 가능.
더빠르고 자주 수행할 수 있어서 자주 배포가능.
개발단계에서도 많은 이점이 있음.
새롭게 추가된 코드 테스트방법 ? 코드가 없으면 로직내에서 호출해봐야 됨. 그래서 더 넓은 범위를 테스트하게 되고, 실패원인 찾기가 어려워짐.
테스트코드만 있으면 범위가 축소, 빠른 피드백, 빠른코드결함 인지 가능.
-> 빠른 피드백과 지속적인 피드백을 통해 안정성, 생산성 향상.
테스트로 검증된 최신 명세의 역할을 하게됨.
2. 심리적 안정감을 얻을 수 있음.
자동화로 잦은 배포가능
안정성 생상성 향상,
최신 명세
심리적 안정감.
2 좋은 테스트 코드?
2-1 빠른테스트
바르고 지속적인 피드백을 위한 안정성 생산성 향상을 위해 테스트가 빨라야 함.
어떻게 빠르게 가능?
- 단위 테스트 비중 높이기. 단위테스트는 백엔드 서버 내부에서만 수행되는 테스트로 범위 정의.
어떻게 높일 수 있음?
주문서 생성 로직과 주문서 저장(db저장)하는 부분 2개를 나누어서 테스트.
통테 -> 단테로 분리하는 방식.
2-2쉽게 깨지지 않는 테스트
자꾸 실패하면 테스트 신뢰도가 떨어짐.
그래서 최소한의코드만 변경하게 되는 경향이 있음.
ex 모킹을 통한 테스트.
테스트 더블 : 테스트 목적으로 실제 사용되는 객체를 교체하는 것. ex 테스트 힘든 외부 api
모킹은 상세구현이 드러나게 되서 변경에 취약하다.
클라이언트 관점에서 생각해보기.
-> 주문서 저장을 기대한다.
클라이언트가 목표하는 행위의 결과를 테스트 -> 1번과 반대되는데/
2-3회귀 방지를 잘해주는 테스트
=코드변경시에 발생하는 문제를 잘 알려주는 테스트
-> 많은 코드를 실행하는 테스트
통테가 단테보다는 회귀 방지를 더 잘해줌.
코드 복잡도가 높은 부분에 작성된 테스트
테스트 작성시 tradeoff 관계에 높인 경우가 많음.
단테 통테 테스트 범위 비중 적절히 나누기
질문 : 1번과 2번이 조금 상반되는 내용 같은데,
2번은 클라이언트가 원하는 목적의 행위 테스트면 통합테스트를 하자는 뜻??
행위 테스트 뜻을 잘 모르겠음
내맘대로 되지 않는 테스트코드, 꼭 작성해야 할까? 절망편
단위 테스트
-뭘 테스트해야함?
-의존성 다루는 법
-디비 모킹하지 않기
1. 현실적인 테스트 코드 작성법
구현 세부사항검증시 깨지기 쉬운 테스트가 된다.
호출 후 최종 상태를 검증하는 것이 좋은 테스트.
최종 상태나 출력결과를 표현 하는 명세 작성하는 것이 좋다.
작성 순서는 작은 단위나 의존성이 거의 없는 영역을 먼저 테스트.
-> 단위 테스트
도메인 규칙이나 알고리즘이 주 영역이 됨.
-엣지 케이스는 어디까지 커버?
의미 없는 케이스나 너무 많은 케이스는 테스트 비용 및 시간 비용이 큼
성공하는 케이스만 있으면
예외발생 상황과 예측힘든 버그 확인 불가
경계값 테스트
ex 2이상 10이하 범위 경계 테스트라면
1,2,3 경게 이전, 경계 값, 경계 초과느낌으로 테스트
존재 유무 기준으로 테스트해볼 수도 있다. 이모지 테스트
내부값을 임의로 자동으로 생성하는 방식
-통테
외부 의존성과 결함된 경우.
의존성을 어떻게 처리?
ex : 리포지토리, 암호화 모듈 -> 비공개 의존성이라 테스트 더블 불필요
예시는 테스트 더블 방식
공유 의존성 : 테스트간 공유되고 결과 영향 미칠 수 있는 수단 제공 의존성 -> 테스트 더블 대상
비공개 의존성 : 시스템 내부 객체간의 의존성.
프로세스 외부 의존성 : ex 데이터베이스 외부에서 실행되는 의존성 -> 테스트 더블 대상
db : 공유, 프로세스 외부 의존성. 그러나 테더 사용하기 적절 x
시스템 외부에서 접근 불가능하고
테스트하려는시스템에서 완전히 제어가 가능한 구현 세부사항이라서.
테더의 적절한 예시
ex : 메일 서버.
외부접근 가능한 비관리 의존성은 외부 시스템 변화에 테스트영향을 받을 수 있어서
테스트 더블이 적절.
프로세스 외부의 공유의존성이고 외부에서 접근가능한 비관리 의존성일 경우 테스트 더블로 교체해야 될 대상이다.
그러면 DB 테스트는 도커나 인메모리 데이터베이스로 인스턴스 연결해서 테스트
사용한 테이블은 초기화하는 로직 필요
암호화모듈 테스트 방법?
최종상태 검증에 집중. 테스트 더블 x
암호화 구현이 드러나면 리팩토링 내성이 적다.
2. 현실적인 고민
테스트 코드 작성시간 확보하기
코드작성시간이 없다..
1. 작성 시간확보
70을 구현, 30을 테스트코드 작성에 사용.
1개 구현 테스트코드 작성, .. 마지막에 리팩토링
명세대로 작성만 한 코드를 70점 짜리 코드
테스트코드 작성시간 = 놓친 기능 파악 + 리팩토링 + 버그 수정 시간.
코파일럿, gpt, 활용
생산성이 비약적으로 향상
테스트 명세를 잘 풀어서 사용. 테스트 코드 명세 작성에 집중할 수 있어서 좋음
대신 검증은 필수
2. 작성 속도
어디까지 테스트할 것인가 생각.
가성비 있는 테스트 작성하기.
도메인 모델 및 알고리즘 컨트롤러 테스트를 권장.
간단한 코드는 생략. 의미가 거의 없어서.
지나치게 복잡한 코드는 너무 어려우니 리팩토링해서 계층 분리하는 방식으로 다른 사분면으로 변경하기
커버리지에 집착하지 않기. 가성비 위주 테스트 진행을 권장.
커버리지가 100이여도 엣지케이스가 나올 수 있다.
낮은 커버리지 방지를 위해 소나큐브를 통해 커버리지를 관리하고 있음.
테스트 다이어트
제거 대상 테스트
=
사용하지 않는 메서드 테스트, 리팩토링하면서 제거되지 않은 중복된 테스트
정리
시간확보
7 3 비율
ai 도움 받기
속도
-가성비
높은 커버리지 노집착
테스트 제거
QnA
통테에 테이블이 많아서 복잡할 떄 외래키 많으면 테이블 데이터 다 생성해서 테스트하는지?
외래키 사용안하므로 테스트객체를 쉽게 만들어서 테스트했어서 테스트 쉬웠음
외부의존성 적용된 프레임워크(ex : 외부 모듈 같은거 PG사나 smtp ) 힘든테스트 사례, 해결 방법
이런경우는 모킹을 자주 썼었음(외부 의존성이라서)
정상적으로 호출되는지, 의도한 파라미터가 잘들어갔는지 여부 검증으로 활용.
-> 출력 값은 활용안했음
출력값은 스터핑? 으로 검증할 수 있을듯
외부 api 지연, 장애, 등 실패할 수 있으므로 스텁?을 사용해서 호출을 정확하게 했는지 상태저장해서
테스트
postman으로 검증하는지?
E2E 테스트 어떻게 하는지 여부?
가끔 포스트맨 사용
E2E 테스트
범위가 너무 넓어서, 필요한, 중요한 api만 작성.
노드 개발하고 있어서 서버찍기 쉬움
E2E 테스트를 즐겨 함.
해피패스를 1 2개 테스트
모킹으로 컨트롤러 영역만 테스트
E2E 테스트 파라미터 가지수가 늘어날 경우
데이터베이스를 더 검증한다거나 서비스 모킹, or 통합 테스트를 철저히 구성
test.ech, 등 돌릴 수 있는 방법이 있음.
질문을 정리를 먼저해주는 모습이 매우 인상깊음
출처
- 사이트, 검색명 (날짜)