Draft: Resolve "Week2/Clustern"

Closes #2 (closed)

4장 테스트 구축하기

리팩터링을 제대로 진행하려면 견고한 테스트 스위트 필요 => 평소에도 견고하게 짜여진 테스트 코드는 개발 효율 증가에 도움

4.1 자가 테스트 코드의 가치

클래스마다 자가 테스트 코드를 요함 => 버그 검출이 쉬워짐, 회귀 버그에도 효과적

기능 추가 시 테스트 코드를 먼저 작성 => 추가 기능의 구체화 및 목표 설정

테스트 주도 개발(TDD, Text-Driven Development)

1. 테스트 작성
2. 테스트 통과를 위해 코드 작성
3. 완성 코드를 리팩터링

==적은 노력에도 효과를 볼 수 있음

4.3 첫 번째 테스트

실패 할 상황에서는 반드시 실패하게 만들자 최소 몇 분 간격으로 자주 테스트하고 하루 한 번 전체 테스트 실행

어서션(assertion) 라이브러리 : 픽스처 검증 라이브러리

4.4 테스트 추가하기

클래스가 하는 일을 보고 발생 가능 오류를 테스트 => public 메서드를 테스트하는 방식과는 다름

테스트는 위험 요인 중심으로 작성할 것 단순 필드 읽기/쓰기 접근자 테스트는 불요 장시간 투자한 완벽한 테스트보다 불완전 테스트라도 작성하여 실행

describe('chai_province', function () {  
    let asia;  
    beforeEach(function () {  
        asia = new Province(sampleProvinceData())  
    });  
  
    it('shortfall', function () {  
        expect(asia.shortfall).equal(5);  
    });  
  
    it('profit', function () {  
        expect(asia.profit).equal(230);  
    });  
})

beforeEach() {} 구문을 활용하여 테스트 실행마다 새로운 asia 를 사용을 권장 beforeEach() 절대신 const asia = new Province... 은 공유 픽스처를 사용하게 되며 어떠한 테스트도 픽스처 값을 변경하지 못하게 하거나 내부 값이 확실히 불변이어야함.

it 구문 하나당 한 개의 검증을 권장 => 앞쪽 검증 실패 시 뒷쪽 검증 스킵

4.6 경계 조건 검사하기

범위는 벗어난 경계 지점에 문제가 초래하는 결과를 보는 테스트도 작성 문제 발생 가능성이 있는 경계 조건 생각하고 집요하게 테스트 => ps. 기본적으로 사용자가 입력하는 값은 믿으면 안된다.

과량의 유효성 검사 코드는 오히려 중복 문제 발생

모든 버그를 잡을 수 없다며 테스트하지 않는다면 버그 자체를 잡는 것도 포기하는 셈이다.

4.7 끝나지 않은 여정

이 장에서 말하는 테스트는 단위 테스트이다. 기능 추가 시 기존 테스트도 다시 체크하고 보강하자

버그 리포트를 받으면 가장 먼저 그 버그를 드러내는 단위 테스트부터 작성하자

충분한 테스트의 기준점은 주관적임

5장 리팩터링 카탈로그 보는법

5.1 리팩터링 설명 형식

1. 이름 : 리팩터링 용어 구축
2. 개요 : 핵심 개념
3. 배경 : 필요성, 적용 부적합 사례
4. 절차 : 리팩터링 과정 제시
5. 예시 : 실제 적용 예, 그 효능

6장 기본적인 리팩터링

추출은 결국 이름 짓기 함수 구성과 이름 짓기는 저수준 리팩터링 => 고수준 모듈로 묶어줘야함

6.1 함수 추출하기

메소드, 프로시저, 서브루틴에도 적용됨

목적과 구현을 분리하는 방식 코드를 통한 목적 파악이 느리면 함수로 추출하고 그 코드의 목적을 함수 이름으로 지어준다 주석을 넣을 것을 함수 이름으로 넣어준다고 생각하면 될 것이다.

짧은 함수는 캐싱하기 쉬우므로 다량의 함수로 인한 속도 감소는 걱정할 필요가 없다.

최적화 할 때는 두 규칙을 따르기 바란다. 첫 번째, 하지 마라. 두 번째(전문가 한정), 아직 하지마라. - M. A. 잭슨

6.2 함수 인라인하기

과도한 간접 호출, 위임 관계가 복잡하게 얽힌 함수가 대상

복잡한 상황이라면 한문장씩 처리한다.

6.3 변수 추출하기

복잡한 표현식을 지역 변수를 활용하여 나눠서 관리 => 복잡한 로직의 구성 단계마다 이름이 붙음

좁은 구역에서는 변수 넓은 구역까지는 함수가 적합

할 일이 많이 늘어날 것 같으면 임시 변수를 질의 함수로 바꾸기(7.4)를 적용 가능 할 때까지 방치