TDD에 대해

가까이보면 느려보이지만 멀리보면 가장 빠른 개발 방법

테스트를 하는 이유

1. 빠른 피드백을 위해
   레이어별로 코드 작성하고… 빌드하고… 포스트맨 돌리고… 하는 시간을 절약할 수 있습니다.

    

2. 자동화된 피드백

   
   사람이 직접 수동으로 확인하는게 아니라 테스트 환경에서 피드백을 받을수 있습니다.

3. 심리적 안정감
   내가 작성한 코드에 대한 안정감, 자신감

귀찮게 느껴지지만 직접 작성해보니 생각보다 많은 시간을 아낄수 있게 도와준다는 인상을 받았습니다.

단위테스트(Unit test)

작은 코드 단위를 독립적으로 검증하는 테스트

클래스, 메소드등 가장 작은 단위를 테스트 하는 것

외부에 의존하지 않음

TDD(Test Driven Development)

사이클의 실패하는 테스트, 최소한의 코딩이 이해되지 않았었는데

극단적인 예시지만 바로 이해를 시켜주셨습니다.

테스트를 먼저 작성하는 이유

기능 먼저 작성하면

1. 기능 먼저 구현시 테스트 자체가 누락될 가능성이 높음 → 귀찮으니까

2. 해피케이스만 검증할 가능성이 높음 → 사고가 갇히게 됨 예외 상황을 예측하기 어려움

3. 잘못된 구현을 늦게 알아차림 → 유지보수가 힘들어 진다.

4. 결국 테스트가 불가능한 코드가 탄생하게 될수도

테스트를 먼저 작성하면

1. 복잡도가 낮은, 테스트가 가능한 코드로 구현이 시작됨

2. 예외 케이스에 대해 생각하므로 문제를 조기에 발견 가능함

3. 과감하게 리팩토링, 구현이 가능하다.

TDD에 대한 오해

테스트의 진짜 목적은 검증이 아닌 상호 작용을 통한 프로덕션 코드의 발전입니다

테스트 코드는 프로덕션 코드에 대한 여러 케이스를 보여주기 때문에

하나의 명세가 될 수 있고 무엇이 필요한지 어떤걸 주의해야할 지 코드로 설명이 가능합니다.

덕분에 프로덕션, 도메인에 대해 여러 시각과 관점을 가질수 있게 되고

이런 장점은 결과적으로 팀의 자산이 되어 팀원 모두에게 도움을 줄 수 있습니다.

하지만 테스트 코드가 병목이 될수도 있다.

그래서 우리가 고민 해야할 것

1. 드러나지 않은, 숨겨진 혹은 암묵적인 요구사항이 없는지
   기획 의도는 대부분 해피케이스를 말합니다 때문에 예외 케이스를 스스로 고민해봐야 합니다 특히 엣지 케이스 경계값 테스. 트가 필요하지 않

2. 우리가 무얼 검증하고 있는것인지 생각해봐야함.
   테스트 코드는 반드시 프로덕션 코드와 같지 않아도 됨 하지만 내가 만드는 기능이 무엇인지 어떤 검증이
   필요한지를 명확하게 해야함

3. 값에 의존하는 코드인지 외부 세계에 영향을 주는 코드인지 판단하기 = 테스트하기 어려운 기능
   값에 의존적이라면 테스트 내부에 있던 값을 파라미터, 상수로 값을 메서드 밖으로 꺼내는걸 고려해야하고
   외부 세계에 영향. 을 준다면 신중하게, 예외처리 등을 섬세하게 처리해주어야 합니다.

회고

테스트 코드를 안개속에 있는것처럼 느끼고 있었는데
너무 쉽고 명확하게 설명을 해주셔서 좋았습니다.

저에게 큰 도움이 된 주차였습니다.