단위 테스트

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

깨끗한 테스트 코드 유지하기

• 테스트 코드는 실제 코드 못지 않게 중요하다.

테스트는 유연성, 유지보수성, 재사용성을 제공한다.

• 테스트 케이스가 있다면 공포는 사실상 사라진다.
• 테스트 케이스가 있으면 변경이 쉬워지기 때문이다.

깨끗한 테스트 코드

• 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.

이중 표준

• 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다.

테스트 당 assert하나

테스트 당 개념 하나

F.I.R.S.T

• F(Fast) : 테스트는 빨라야 한다.
• I(Independent) : 각 테스트는 서로 의존하면 안 된다.
• R(Repeatable) : 테스트는 어떤 환경에서도 반복 가능해야 한다.
• S(Self-validating) : 테스트는 부울(boolean)값으로 결과를 내야한다. 성공 아니면 실패다.
• T(Timely) : 테스트는 적시에 작성해야한다.

클래스

클래스는 작아야 한다.

• 클래스 이름은 해당 클래스 책임을 기술해야 한다.
• 클래스 설명은 만일(“if”), 그리고(“and”), -(하)며(“or”), 하지만(“but”)을 사용하지 않고서 25단어 내외로 가능해야 한다.

단일 책임 원칙

• 단일 책임 원칙 : 클래스나 모듈은 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다.
• 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.
• 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이워진 시스템이 더 바람직하다.

응집도

• 응집도가 가장 높은 클래스는 가능하지도 바람직하지도 않다.
• 응집도를 유지하면서 작은 클래스 여럿이 나오게 한다.
  • 큰 함수를 작은 함수 여럿으로 쪼개다 보면 종종 작은 클래스 여럿으로 쪼갤 기회가 생긴다. 그러면서 프로그램에 점점 체계가 잡히고 구조다 투명해진다.

변하기 쉬운 클래스

• 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장 할 뿐 기존 코드를 변경하지 않는다.
• 변경으로부터 격리
  • 결합도가 낮다는 소리는 각 시스템 요소가 다른 요소로부터 그리고 변경으로부터 잘 격리되어 있다는 의미다.
  • 결합도를 최소로 줄이면 잘연스럽게 클래스가 상세한 규현이 아니라 추상화에 의존하게 된다.