테스트 주도 개발로 배우는 객체 지향 설계와 실천

테스트 주도 개발을 활용해서 객체 지향 설계를 잘 할 수 있다.

TDD 의 핵심

1. 학습 과정에서의 SW 개발
   → 이미 해결방법을 알거나 한 번 해본 건 거의 큰 문제가 되지 않는다. ( 그러나, 모르는 부분에 대한 건 문제가 될 경우가 많다. )

   즉, SW 개발은 학습의 영역에 중점을 많이 둔다. 
   
   개발을 할 때 거의 잘 모르는 부분에 대해서 개발을 하게 될 거고 그에 따라 지속적인 학습을 하게 된다. 
   
   엔지니어를 뽑을 때 빠르게 배우고 적용할 수 있는 사람을 원하는 이유도 비슷하다.

2. 피드백은 가장 기본적인 도구다.
   → 컴파일할 때 에러가 생기는 에러 코드도 일 종의 피드백이고 IDE의 빨간 줄도 피드백의 일종이기에 그런 피드백으로도 학습한다.

   피드백을 더 빨리 받아야 한다. ( 페어 프로그래밍도 좋은 방법 )
   
   Unit testing : low level 에서 테스트 가능한지 확인 ( 함수 하나 )
   
   Integration Testing : 통합 테스트 ( 기능이 맞느냐 )
   
   System Testing : SW 스펙 테스트
   
   Acceptance Testing

3. 테스트 코드를 쉽게 짤 수 있는 코드가 좋은 코드다.
   -> 테스트는 시스템 구현의 피드백을 얻을 수 있고 시스템 설계의 피드백을 얻을 수 있다.
   피드백을 더 빨리 받아야 한다. ( 페어 프로그래밍도 좋은 방법 )
   

4. 인수 테스트 범위 != 단위 테스트 범위
   -> 단위 테스트의 영역이 함수 하나를 검증하는 거지만 함수 내에 다른 메소드를 호출하거나 그러면 단위 테스트라기엔 범위가 조금 크지 않을까.

전 구간 테스트 (end-to-end test, E2E test)

-> 내부에서 상호작용하는 게 아니라 외부와 상호작용해라
DB도 외부로 볼 수 있고 cloud를 포함한 작업들도 외부 테스트로 볼 수 있다.

단, 경계간 테스트(edge-to-edge test)와 구분하자.
경계간 테스트 : 단순히 데이터를 확인만 하는 것

ex)
경계간 테스트 - 국민은행 서버가 잘 돌아가는지 확인하는 것
전구간 테스트 - 국민은행 서버와 통신하여 송금이 되는지 확인하는 것

인수 테스트 VS 통합 테스트 VS 단위 테스트

인수 테스트 : 전체 시스템이 동작하는가
통합 테스트 : 바깥 코드까지 포함해서 잘 동작하는가
단위 테스트 : 객체 코드가 잘 동작하는가
( 용어는 관점, 사람마다 차이가 있을 수 있다 )

TDD 사용 -> 피드백 -> 예쁜 코드 -> 객체 지향적 설계

외부 품질과 내부 품질

외부 품질 - 고객 입장에서 잘 되는지
내부 품질 - 우리 입장(개발자 입장)에서 잘 되는지

Unit Test 통과와 외부 품질을 보면 Unit Test를 짤 때 외부 품질 고려 X
Unit Test는 개체가 뭘 해야하고 api가 무슨일을 해야하는지.

구현이 예쁜 코드가 단위 테스트 작성에 유리하다.