- 단위테스트의 가치
- 개발자 생산성을 향상하는 테스트
- 설계 도구로써의 테스트
더 좋은 테스트
테스트를 코딩이 끝나면 다른 사람이 해주는 일 혹은 코딩이 다 끝냈다고 선언하기 전에 자신이 짠 코드를 이리저리 찔러보는 정도로 치부하던 시절.
자동화된 테스트는 개발자가 직접 작성해야 하고, 그중 하나라도 실패하면 빌드 전체가 실패한다라는 인식은 널리 퍼졌다.
테스트 선행 방식에서는 자동화된 테스트를 단순한 오류 예방 목적으로뿐 아니라, 코딩 전에 그 코드에 기대하는 동작을 정의하는 설계보조 수단으로 까지 활용한다.
테스트의 가치
- 테스트는 실수를 바로잡아준다. (재작업 방지)
- 테스트는 실사용에 적합한 설계를 끌어준다. (사용자의 시각으로 바라본다.)
- 테스트는 원하는 동작을 명확히 알려주어 군더더기를 없애준다.
- 테스트 작성 과정에서 깨달음을 얻는다.
100% 코드 커버리지가 중요한게 아니다. 확인하지 못한 코드가 어떤 것인가와 테스트 코드가 프로그래밍 실수를 어마나 정확하게 잡아내는가에 좌우된다. 의미있는 테스트에 집중하라. 100%에 근접할수록 코드에서 문제가 발견될 가능성은 낮아진다. 수확체감의 법칙에 따라 100%에 근접할수록 변화를 체감하기 어렵다.
생산성에 영향을 주는 요소
- 엉터리로 작성된 테스트 코드는 안정성, 신뢰성, 실행 속도에 악영향을 준다.
- 테스트 실행 속도, 가독성, 테스트 결과의 정확성(신뢰성과 안정성)
- 설계 잠재력 곡선 : 수확체감에 다다르면 단지 테스트만 작성해서 얻을 수 있는 한계점이 있다.
- 테스트 코드도 제품 코드다루듯이 하라.
- 테스트코드를 목적과 씀이새에 적합한 구조가 되게끔 설계수단으로 활용하라.
설계 수단으로써의 테스트
- 설계 수단으로 사용하면
- AS-IS : 설계 - 코딩 - 테스트
- TO-BE : 테스트 - 코딩 - 설계
- 결과 : 테스트 - 코딩 - 리팩토링
- 테스트를 먼저하면
- 테스트 선행 프로그래밍, 테스트 주도 개발
- 사용가능한 코드 : 제품코드의 설계가 API 활용 시나리오에 맞게된다.
- 가벼운 코드 : 실제로 활용할 시나리오에서 용구하는 기능만 담는다.
- 우발적 복잡성을 줄인다.
- BDD (Behavior Driven Development) 행위 주도 개발
software develop engineer