ch04

⬅️ 3장 | 6장 ➡️

4장 테스트 구축

• 4.1 자가 테스트 코드의 가치
• 4.2 테스트할 샘플 코드
• 4.3 첫 번째 테스트
• 4.4 테스트 추가하기
• 4.5 픽스처 수정하기
• 4.6 경계 조건 검사하기
• 4.7 끝나지 않은 여정

Note

'테스트 구축' 챕터는 다음 질문을 중심으로 읽어나가시면 좋습니다.

1. 테스트는 왜 해야 하는가
2. 무엇을 테스트해야 하는가
3. 어떻게 테스트를 발전시킬 수 있는가

p133

1. 리팩터링은 분명 가치 있는 도구지만, 그것만으로는 부족하다. 리팩터링을 제대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위치가 뒷받침돼야 한다.

4.1 자가 테스트 코드의 가치

p.134

1. 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자
2. 자가 테스트 코드 자체뿐 아니라 테스트를 자주 수행하는 습관도 버그를 찾는 강력한 도구가 된다.
3. 테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는 데 걸리는 시간을 대폭 줄여준다.

p.135

1. 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다.
2. 구현보다 인터페이스에 집중하게 된다는 장점도 있다.
3. 켄트 벡은 이처럼 테스트부터 작성하는 습관을 바탕으로 테스트 주도 개발이란 기법을 창시했다. TDD에서는 (처음에는 통과하지 못할) 테스트를 작성하고, 이 테스트를 통과하게끔 코드를 작성하고, 결과 코드를 최대한 깔끔하게 리팩터링하는 과정을 짧은 주기로 반복한다. 이러한 테스트-코딩-리팩터링 과정을 한 시간에도 여러 차례 진행하기 떄문에 코드를 대단히 생산적이면서도 차분하게 작성할 수 있다. TDD에 대해서는 여기서 자세히 설명하지 않지만, 내가 프로그래밍하는 방식이자 추천하는 방식이다.
4. 리팩터링에는 테스트가 필요하다. 그러니 리팩터링하고 싶다면 테스트를 반드시 작성해야 한다.

4.2 테스트할 샘플 코드

p.139

1. 나는 이런 코드를 목격하면 리팩터링해서 제거하고 싶어지지만, 그러려면 먼저 테스트를 작성해야 한다.

4.3 첫 번째 테스트

p.140

1. 첫 번째 단계에서는 테스트에 필요한 데이터와 객체를 뜻하는 픽스처를 설정한다.
2. 두 번째 단계에서는 이 픽스처의 속성들을 검증하는데, 여기서는 주어진 초깃값에 기초하여 생산 부족분을 정확히 계산했는지 확인한다.

p.141

1. 실패해야 할 상황에서는 반드시 실패하게 만들자.
2. 각각의 테스트가 실패하는 모습을 최소한 한 번씩은 직접 확인해본다. 이를 위해 내가 흔히 쓰는 방법은 일시적으로 코드에 오류를 주입하는 것이다.
3. 자주 테스트하라. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자.

p.142

1. 모카 프레임워크는 소위 어서션(assertion) 라이브러리라고 하는 픽스처 검증 라이브러리를 선택해 사용할 수 있다.
2. 이 책에서는 차이 라이브러리를 사용하겠다. 차이를 사용하면 다음과 같이 assert문을 이용해 코드를 검증할 수 있다.
3. 개인적으로 assert를 선호하지만 자바스크립트를 다룰 때는 expect를 주로 사용할 것이다.
4. "실패한 테스트가 하나라도 있으면 리팩토링하면 안 된다."라는 의미로 흔히들 "빨간 막대일 때는 리팩터링하지 말라"라고 말한다.

p.143

1. 한편 "최근 변경을 취소하고 마지막으로 모든 테스트를 통과했던 상태로 돌아가라"라고 전하고 싶을 때는 "초록 막대로 되돌려라"라고 말한다.
2. 나는 이맥스(유닉스 코드 에디터)에서 키 하나만 누르면 테스트 전체를 실행하도록 만들어 두고, 컴파일 창에 텍스트로 출력된 결과를 확인하는 방식도 많이 쓴다.

💡 의견

1. assert 와 expect의 차이
2. 모카, jest 등을 많이 사용하는데 npm 트랜드에서는 jest를 가장 많이 사용.
3. UI 테스트의 경우 스토리북, E2E 테스트는 Cypress, 유닛 테스트는 jest & RTL 사용
4. https://tosspayments-dev.oopy.io/share/books/unit-testing 토스 유닛 테스트 글

4.4 테스트 추가하기

p.143

1. 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 게 낫다.

💡 의견

공유 인스턴스가 있을때 beforeEach를 사용하면 독립성을 보장한다.

p.144

1. 사실 나는 먼저 기대값 자리에 임의의 값을 넣고 테스트를 수행한 다음, 프로그램이 내놓는 실제 값(230)으로 대체했다.
2. 총수익 계산 로직에 * 2를 덧붙여서 잘못된 값이 나오도록 수정한다.
3. 임시 값을 설정했다가 실제 값으로 대체하고, 오류를 심었다가 되돌리는 이 패턴은 실제로 내가 기존 코드를 검사하는 테스트를 추가할 때 흔히 쓰는 방식이다.
4. 일반 코드와 마찬가지로 테스트 코드에서도 중복은 의심해봐야 한다.
5. 테스트 관련 버그 중 가장 지저분한 유형인 '테스트끼리 상호작용하게 하는 공유 픽스처'를 생성하는 원인이 된다.

p.145

1. beforeEach 구문은 각각의 테스트 바로 전에 실행되어 asia를 초기화하기 때문에 모든 테스트가 자신만의 새로운 asia를 사용하게 된다.
2. 내가 이렇게 조언하면 매번 픽스처를 생성하느라 테스트가 느려지지 않냐고 묻는 사람이 있다. 눈에 띄게 느려지는 일은 거의 없다
3. 또한 불변임이 확실한 픽스처는 공유하기도 한다.
4. 가장 선호하는 방식은 매번 새로운 픽스처를 만드는 것이다.

4.5 픽스처 수정하기

p.146

1. 하지만 Producer의 production() 세터는 좀 복잡한 동작을 수행하기 때문에 테스트해볼 필요가 있다.
2. 테스트에 관해 공부를 좀 했다면 이 패턴을 설정-실행-검증(setup-exercise-verify), 조건-발생-결과(given-when-then), 준비-수행-단언(arrange-act-assert)등으로 부른다는 것을 알 것이다.
3. 일반적으로 it 구문 하나당 검증도 하나씩만 하는게 좋다. 앞쪽 검증을 통과하지 못하면 나머지 검증은 실행해보지 못하고 테스트가 실패하게 되는데, 그러면 실패 원인을 파악하는 데 유용한 정보를 놓치기 쉽기 떄문이다.

💡 의견

버그리포트는 목적이 확실하고 나중에 문제해결하는 데 적은 시간이 들것 같다.

함수 하나가 하나의 기능을 수행해야 하는 것처럼 하나의 it 구문은 하나의 테스트를 수행하도록 해야겠다.

4.6 경계 조건 검사하기

p.147

1. 이 범위를 벗어나는 경계 지점에서 문제가 생기면 어떤 일이 벌어지는지 테스트도 함께 작성하면 좋다.

p.148

1. 이처럼 경계를 확인하는 테스트를 작성해보면 프로그램에서 이런 특이 상황을 어떻게 처리하는 게 좋을지 생각해볼 수 있다.
2. 문제가 생길 가능성이 있는 경제 조건을 생각해보고 그 부분을 집중적으로 테스트하자.

p.149

1. 실패란 검증 단계에서 실제 값이 예상 범위를 벗어났다는 뜻이다. 에러는 성격이 다르다.
2. 같은 코드베이스의 모듈 사이에 유효성 검사 코드가 너무 많으면 다른 곳에서 확인한 걸 중복으로 검증하여 오히려 문제가 될 수 있다.

p.150

1. 나는 리팩터링하기 전이라면 이런 테스트를 작성하지 않을 것이다. 리팩터링은 겉보기 동작에 영향을 주지 않아야 하며, 이런 오류는 겉보기 동작에 해당하지 않는다.
2. 이런 오류로 인해 프로그램 내부에 잘못된 데이터가 흘러서 디버깅하기 어려운 문제가 발생한다면 어서션 추가하기를 적용해서 오류가 최대한 빨리 드러나게 하자.
3. 어차피 모든 버그를 잡아낼 수는 없다고 생각하여 테스트를 작성하지 않는다면 대다수의 버그를 잡을 수 있는 기회를 날리는 셈이다.
4. 테스트가 모든 버그를 걸러주지는 못할지라도, 안심하고 리팩터링할 수 있는 보호막은 되어준다.
5. 리팩터링을 하면서 프로그램을 더욱 깊이 이해하게되어 더 많은 버그를 찾게 된다.

4.7 끝나지 않은 여정

p.151

1. 이 장에서 보여준 테스트는 단위 테스트에 해당한다. 단위 테스트란 코드의 작은 영역만을 대상으로 빠르게 실행되도록 설계된 테스트다. 단위 테스트는 자가 테스트 코드의 핵심이자, 자가 테스트 시스템은 대부분 단위 테스트가 차지한다.
2. 한 번에 완벽한 테스트를 갖출순 없다. 나는 제품 코드에 못지않게 테스트 스위트도 지속해서 보강한다.
3. 다시 말해 기능을 새로 추가할 때마다 테스트도 추가하는것은 물론, 기존 테스트도 다시 살펴본다.
4. 버그 리포트를 받으면 가장 먼저 그 버그를 드러내는 단위 테스트부터 작성하자.
5. 테스트 커버리지를 기준으로 삼는 사람도 있지만, 테스트 커버리지 분석은 코드에서 테스트하지 않은 영역을 찾는 데만 도움될 뿐, 테스트 스위트의 품질과는 크게 상관 없다.

p.152

1. 테스트 스위트가 충분한지를 평가하는 기준은 주관적이다. 가령 '누군가 결함을 심으면 테스트가 발견할 수 있다는 믿음'을 기준으로 할 수 있다.
2. 리팩터링 후 테스트 결과가 모두 초록색인 것만 보고도 리팩터링 과정에서 생겨난 버그가 하나도 없다고 확실할 수 있다면 충분히 좋은 테스트 스위트라 할 수 있다.
3. 테스트 때문에 개발 속도가 느려진다고 생각되면 테스트를 과하게 작성한건 아닌지 의심해보자
4. 하지만 너무 많은 경우보다는 너무 적은 경우가 훨씬 훨씬 많다.

💡 의견

TDD를 하고 있는 분들이 있는지

테스트 커버리지가 높을수록 무조건 좋은것인지

모든 곳에 테스트 코드를 작성하는 것이 오히려 생산성을 낮출 수 있다고 생각

⬅️ 3장 | ⬆️ 위로 | 6장 ➡️