들어가기전에
- 책 내용을 요약해 스스로 정리하는 포스트
서론
- 테스트 주도 개발은 언뜻 보기에는 단순한 아이디어다.
테스트 주도 개발의 핵심은 무엇인가?
- 불확실한 변화를 예측하려면 불확실성을 해결하는데 도움이 될 프로세스가 있어야 한다.
테스트 주도 개발의 핵심 주기
- 테스트를 작성한다.
- 해당 테스트가 동작하게 만들 코드를 작성한다.
- 코드를 가급적 테스트한 기능의 단순 구현으로 리팩토링 한다.
- 반복한다.
이 과정을 통해 시스템 구현의 안정성과 설계의 품질에 대한 피드백을 받는다.
테스트 주도 개발의 황금률
- 실패하는 테스트 없이는 새 기능을 작성하지 말라.
인수 테스트 ( Acceptance Test )
- 만들고자 하는
기능을 시험하는 테스트
실패하는 기능 또는 인수 테스트
- 고리 중첩 TDD
- 실패하는 인수 테스트를 작성한다.
- 테스트를 작성한다.
- 해당 테스트가 동작하게 만들 코드를 작성한다.
- 코드를 가급적 테스트한 기능의 단순 구현으로 리팩토링 한다.
- 반복한다.
- 인수 테스트를 반복한다.
- 실패하는 단위 테스트는 소스 저장소에 커밋하지 않는다.
전 구간 테스트
- 외부에서 유래되는 시스템과 상호 작용하는 것 이상을 뜻함
- 시스템과 해당 시스템을 구축하고 배포하는 프로세스를 모두 시험하는 방식
push 시점에서 단위 테스트 실행 후 패키지화 하고, 현실적인 운영 환경 수준에 배포된 후 외부 접근 지점을 통해 시스템을 시험
DevOps보다 더 나아가 실제 환경 테스트를 얘기하는 듯
배포는 인수 테스트가 모두 통과할때 배포한다.
테스트의 수준
- 인수 테스트 : 전체 시스템이 동작 하는가?
- 통합 테스트 : 변경할 수 없는 코드를 대상으로 코드가 동작하는가?
- 단위 테스트 : 객체가 제대로 동작하는가? 객체를 이용하기 편리한가?
변경할 수 없는 외부 라이브러리나 코드 테스트를 가리켜 통합 테스트라 한다.- 용어는 조직마다, 팀마다 그 의미가 대동소이하다.
결합도와 응집도
- 결합도와 응집도는 일부 코드의 동작 방식을 얼마나 쉽게 바꿀 수 있는지를 대략적으로 설명하는 척도다.
래리 콘스탄틴(Larry Constantine), [Yonrdon79]
결합도
한 변경이 다른 것의 변경을 강제한다면 요소들이 결합된 상태다. 예를 들어, 두 클래스가 공통 부모로부터 상속할 경우 한 클래스를 변경하면 다른 클래스를 변경해야 할지도 모른다. 각기 분리된 컴포넌트로 어떤 기계를 조립한다면, 한 컴포넌트가 고장났을때, 전체를 교체할 필요 없이 고장난 컴포넌트만 교체하면 되므로, 느슨하게 결합된 기능이 유지보수하기 더 쉽다.
큰 그림으로 봤을때,
소프트웨어를 컴포넌트 별로 나누고, 컴포넌트를 조합한 형태로 구조화 한다면, 유지보수가 쉬워질 것이라는 얘기인 것 같다.
응집도
한 요소의 응집도는 해당 요소의 책임이 의미 있는 단위를 형성하는지 나타내는 척도다. URL과 날짜를 모두 파싱하는 클래스는 응집력이 없는데, 두 일은 서로 관련이 없는 개념이기 때문이다. 응집도가 높은 기능은 유지보수 하기 쉽다.
한개의 클래스에는 한가지 속성만 가진다. 라는 원칙도
응집도와 연관이 있는 내용인것 같다. 다만 클래스에 여러가지 기능이 있더라도 관련 있는 기능이 뭉쳐야 한다는 내용인것 같다.
마치며
- 오늘은 여기까지, 책 여러권을 하루에 조금씩 읽으며 집중력있고 꾸준하게 읽어나갈 참이다.
사람은 행함으로써 배워야 한다. 안다고 여기는것도 직접 해보지 않는 이상 확신할 수 없다. - 소포클레스