IT LAB

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 2. 런던파와 고전파격리 특성에 따라 나뉨 런던파작은 코드 조각 단위테스트 대상 시스템을 협력자에게서 완전히 격리모든 의존성을 Mock으로 대체코드 조각을 테스트 대역으로 분리 (단, 불변 비공개 의존성은 제외) 하향식 TDD전체 설계와 인프라부터 준비하고, 이를 기반으로 상위 레벨 테스트 및 하위 레벨 구현 장점입자성테스트 실패 시, 코드베이스의 어느 부분이 고장 났는지 명확히 알 수 있음의존성에서 문제가 발생하면 테스트가 실패함SUT의 문제인지 직관적으로 확인할 수 없음객체 그래프를 분할할 수 있음객체 그래프를 재생성하지 않아도 됨서로 연결된 클래스의 그래프가 커져도 테스트 용이 단점과잉 명세과도한 명세로 인해 테스트가 SUT의 세부..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. '단위 테스트'의 정의단위 테스트란작은 코드 조각 단위로빠르고 자동으로 실행격리된 방식 격리단위 테스트는 격리된 환경에서 실행되야 함테스트는 순서에 의존하지 않아야 하며, 독립적으로 실행 가능한 상태여야 함 공유 의존성테스트 간에 공유되고 서로의 결과에 영향을 미칠 수 있는 상태나 데이터상태변경이 허용될 경우, 테스트 간 영향을 끼칠 수 있음공유 의존성을 제거하거나, 모의 객체로 대체정적 가변 필드 등 비공개 의존성애플리케이션의 실행 흐름에서 보이지 않는 의존성메모리 기반의 프록시로 대체데이터베이스 연결, 시스템 접근 등 프로세스 의존성애플리케이션 실행 프로세스 외부에서 실행되는 의존성의존성을 대체할 Mock 시스템 사용메시지 큐, ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 테스트 스위트 품질 측정을 위한 커버리지 지표커버리지 지표테스트 스위트가 소스 코드를 얼마나 실행하는 지를 백분율로 나타내는 지표테스트 스위트의 품질을 평가하는데 자주 사용됨 문제점public String categorizeAge(int age) { if (age 테스트 대상 시스템의 모든 가능한 결과를 검증한다 보장할 수 없음 @Testpublic void testIsValidInput() { assertTrue(isValidInput("abcdef")); // 단일 입력값만 테스트}private boolean isValidInput(String input) { return StringUtils.isNotEmpty..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 1. 단위 테스트 현황비율제품 코드와 테스트 코드의 비율은 1:1~3 정도 새로운 기능과 버그 발생새로운 기능을 구현할 때 새로운 버그가 지속적으로 나타남 테스트 코드 작성의 어려움적절하지 않은 설계의 코드를 테스트할 경우, 테스트 코드를 작성하는데 어려움이 있음잘못된 테스트 코드는 오히려 상황을 더 악화시킬 수 있음 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 값을 참조로 바꾸기 데이터를 갱신해야 할 ..

지금까지는 프로그램 요소를 생성 혹은 제거하거나 이름을 변경하는 리팩터링을 다뤘다. 여기에 더해 요소를 다른 컨텍스트(클래스나 모듈 등)로 옮기는 일 역시 리팩토링의 중요한 축이다. 8.1 함수 옮기기 함수가 자신이 속한 모듈 A보다 다른 모듈 B를 더 많이 참조한다면 모듈성을 높이기 위해 서로 연관된 요소들을 함께 묶고, 요소 사이의 연결 관계를 쉽게 찾고 이해할 수 있도록 해야 함. 함수를 옮길 시에 대상 함수의 현재 컨텍스트와 후보 컨텍스트를 둘러보면 도움이된다. 8.2 필드 옮기기 데이터 구조가 적절치 않음을 깨달으면 곧바로 수정하기 (어떤 레코드를 넘길 때마다 또 다른 레코드의 필드도 함께 넘기고 있다면 데이터 위치를 옮겨야 할 것) 필드 캡슐화 => 필드값을 외부에서 변경하지 못하게 할 시 사..

모듈을 분리하는 가장 중요한 기준은 아마도 시스템에서 각 모듈이 자신을 제외한 다른 부분에 드러내지 않아야 할 비밀을 얼마나 잘 숨기느냐에 있을 것이다. 이러한 구조는 캡슐화를 통해 숨길 수 있다. 7.1 레코드 캡술화하기 간단한 레코드 캡슐화하기 변수 캡슐화를 한 후, 데이터 구조를 표현하는 클래스를 정의하고, 이를 반환하는 함수를 새로 만듬 중첩된 레코드 캡슐화하기 변수 캡슐화를 한 후, 데이터 구조를 표현하는 클래스를 정의하고, 이를 반환하는 함수를 새로 만듬 데이터 구조 안으로 들어가는 코드를 세터로 뽑아 작업함. 7.2 컬렉션 캡슐화하기 컬렉션을 소유한 클래스를 통해서만 원소를 변경하도록 캡슐화하기 => 컬렉션 변경자 메서드를 통해 원소를 변경하도록 하여 원본 모듈 밖에서 컬렉션을 수정하지 않도..