IT LAB

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 좋은 단위 테스트의 4대 요소요소설명문제 상황 / 원인해결 방안회귀 방지코드 수정 후 기능이 깨지는 것을 방지하는 테스트 역할코드 수정 후 테스트는 통과하지만 실제로는 동작하지 않음기존 동작을 명확히 검증리팩터링 내성코드 내부 구현이 변경되어도 테스트가 정상적으로 동작해야 함리팩토링 시 내부 동작 테스트 깨짐결과 기반 테스트구현 디테일 분리빠른 피드백테스트가 빠르게 실행되어야 실시간 피드백이 가능외부 의존성으로 느려지거나 무거워짐의존성 분리 (Fake/Stub)유지 보수성가독성, 유지 비용, 실행 비용 등을 평가 └ 이해 난이도테스트가 얼마나 직관적이고 쉽게 읽히는가복잡한 준비 코드AAA 패턴 사용설명적인 테스트 이름└ 실행 난이도..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. AAA 패턴테스트 코드를 세 단계로 구분하여 작성하는 패턴스위트 내 모든 테스트가 단순하고 균일한 구조를 갖게함단계설명Arrange테스트 대상(SUT) 및 의존성 설정Act테스트 대상 메서드 실행Assert결과 확인 (반환 값, 상태 변화, 호출 여부 등) 2. 권장 사항항목권장 사항이유 및 설명구절 수 제한한 테스트에는 한 act만단일 동작 검증조건문 회피분기문 피하기 (if, switch 등)복잡도 증가 (한 테스트에 여러 경우를 넣지 말고 분리해야 함)메서드 캡슐화복잡한 검증 로직 분리 (private 메서드로)반복 제거가독성 향상목적 명확화불변 위반 방지여러 호출로 결과 만들지 말 것불변성 깨질 수 있음 (한 동작 = 한 결과..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 2. 런던파와 고전파격리 방식에 따라 크게 두 가지 스타일로 나뉨항목런던파 (London School)고전파 (Classical School)중심 철학상호작용 기반 (행위 검증)상태 기반 (결과 검증)테스트 단위코드 조각단일 동작TDD 방식하향식 (전체 설계/인프라 → 상위 → 하위)상향식 (하위 → 상위 → 전체 설계/인프라)의존성 처리모든 의존성을 Mock으로 대체공유 의존성만 Fake/Stub으로 격리 (나머지는 실제 객체 사용)장점빠르고 정밀함현실적인 테스트단점과잉 명세구현 의존성 높음문제 원인 추적이 어려움 예제) EmailSender더보기런던파// 인터페이스public interface EmailSender { void ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. '단위 테스트'의 정의작은 코드 조각을 대상으로, 독립적으로 빠르게 검증하는 테스트 격리성독립적으로 실행 가능한 상태✅ 실행 환경이나 다른 테스트에 영향받지 않음✅ 순서에 의존하지 않아야 함 2. 의존성내 코드가 직접 사용하지만, 내가 직접 구현하지 않은 것 (외부에 기대는 요소)✅ 단위 테스트의 격리성을 보장하기 위해 실제 의존성과 함께 동작하지 않음➡️ 테스트 대역으로 대체하여 핵심 로직만 집중적으로 검증의존성 종류설명문제점예시해결 방법공유 의존성테스트 간에 공유되는 상태테스트 간 간섭 발생- 정적 가변 필드- 싱글턴- 전역 변수- 공유 제거- 테스트마다 초기화비공개 의존성코드에 드러나지 않는 숨은 의존성실패 원인 파악 어려움- ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 테스트 스위트 품질 측정커버리지 지표테스트에 의해 실행된 코드의 비율✅ 테스트 스위트의 품질을 평가하는데 자주 사용됨종류항목설명공식코드 커버리지전체 코드 중, 테스트 실행 시 실행된 라인의 비율실행된 코드 라인 수 / 전체 코드 라인 수분기 커버리지모든 분기가 테스트되었는지 측정➡️ 코드 커버리지보다 더 정밀하고 정확한 테스트 평가 가능통과한 분기 수 / 전체 분기 수 예시) 분기 커버리지더보기public boolean isEligibleForDiscount(int age, boolean hasCoupon) { if (age >= 18) { // 분기 1 if (hasCoupon) { // 분기 2 ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 1. 소프트웨어 엔트로피코드베이스는 시간이 흐를수록 복잡성과 불확실성이 증가하는 경향이 있음 흐름⚠️ 엔트로피 증가: 코드 변경 시, 복잡도가 증가함➡️ 예기치 못한 문제 발생: 복잡한 코드에 새 기능을 추가하면 부작용 발생 가능성이 커짐➡️ 신뢰성 하락: 테스트가 없는 프로젝트는 처음엔 빠르게 개발되지만, 시간이 갈수록 코드 작성이 급격히 느려짐 2. 테스트 코드 작성의 중요성새로운 기능을 개발할 때마다 새로운 버그 가능성이 존재함✅ 코드 설계가 적절하지 못하면 테스트 코드 작성이 어려워지고, 테스트 코드 자체도 오류를 포함할 수 있음⚠️ 잘못된 테스트 코드는 신뢰성을 떨어뜨려, 상황을 더 악화시킬 수 있음➡️ 테스트 코드의 품질도 본..

12.1 메서드 올리기 12.2 필드 올리기 12.3 생성자 본문 올리기 생성자는 할수 있는 일과 호출순서에 제약이 있음 (생성될 때만 호출, 리턴 X, 오브젝트 초기화 용도) 부모-자식의 클래스 중, 생성자 호출 단계에서 부모의 생성자를 호출하지 않는 자식의 경우가 있다면 체크 후 자식 생성자에 따로 알맞은 로직을 호출하도록 코딩한다 12.4 메서드 내리기 12.5 필드 내리기 12.6 타입 코드를 서브클래스로 바꾸기 타입코드 비슷한 대상들을 특정 특성에 따라 구분해야 할 때 서브 클래스로 생성하여 조건에 따라 다르게 동작하는 다형성 제공하기 특정 타입에서만 의미가 있는 값을 사용하는 필드나 메서드가 있을 때 사용하기 직접 상속 Employee를 상속한 클래스가 타입에 따라 Engineer, Manag..

모듈과 함수는 소프트웨어를 구성하는 빌딩 블록이며, API는 이 블록들을 끼워 맞추는 연결부다. 이런 API를 이해하기 쉽고 사용하기 쉽게 만드는 일은 중요하며 어렵다. 그래서 API를 개선하는 방법을 새로 깨달을 때마다 그에 맞게 리팩터링 해야한다. 11. 1 질의 함수와 변경 함수 분리하기 목표 : “부수 효과” 없애기 겉보기 부수 효과가 전혀 없이 값을 반환해주는 함수를 추구해야 함 Get함수 안에 set이 같이 있는 경우 11. 2 함수 매개변수화하기 두 함수의 로직이 아주 비슷하고 단지 리터럴 값만 다르다면? 하나의 함수로 만들고 중복 없애기 매개변수로 boolean값을 써서 제어에 쓰는 경우 아님 11.3 플래그 인수 제거하기 호출할 수 있는 함수들이 무엇이고 어떻게 호출해야 하는지를 이해하기..

조건부 로직을 이해하기 쉽고 깔끔하게 만들어야 프로그램의 전체 코드가 복잡하지 않게된다. 10.1 조건문 분해하기 조건, 분기 모두 함수로 추출해버려 가독성 높이기 왜 이 코드가 실행되는 지 모를때가 많음 10.2 조건식 통합하기 비교하는 조건은 다르지만 그 결과로 수행하는 동작은 똑같은 코드들이 있다. 이럴 때 and나 or연산자를 사용하여 여러 개의 비교 로직을 하나로 합칠 수 있다. 간단한 여러 조건문을 하나의 복잡한 조건문으로 통합하기 부수효과에 유의하기 10.3 중첩 조건문을 보호 구문으로 바꾸기 보호 구문 : 한쪽만 정상이라면 비정상 조건을 if로 검사한 다음, 조건이 참이면 함수에서 빠져나온다. if절과 else절에 똑같은 무게를 두어, 코드를 읽는 이에게 양 갈래가 똑같이 중요하다는 뜻을 ..

데이터 구조에 집중한 리팩터링 9.1 변수 쪼개기 변수 1개당 역할은 하나이다 역할이 둘 이상인 변수가 있다면 쪼개야 한다. (여러 용도로 쓰인 변수는 코드를 읽는 이에게 커다란 혼란을 줌) 같은 역할에 여러 번의 할당은 필요할 때도 있다 -> 루프변수, 수집변수 9.2 필드 이름 바꾸기 점진적으로 안전하게 바꾸기 9.3 파생 변수를 질의 함수로 바꾸기 9.4 참조를 값으로 바꾸기 객체 내부를 수정하던 것을, 값 객체 통채 하나로 바꾸기 ( 불변 데이터이므로 외부에 건네주는 경우 등 나중에 그 값이 바뀌어 내부에 영향 끼치지 않음 ) 새로운 속성을 담은 객체로 기존 내부 객체를 통채로 대체 값 객체 - 불변 : setter없이 constructor 만으로 9.5 값을 참조로 바꾸기 데이터를 갱신해야 할 ..