현재 Profile 클래스는 데이터 모델로서의 역할과 매처로서의 역할을 다 가지고 있습니다. 클래스는 변경할 때 한 가지 이유만 있어야 합니다. 클래스는 작고 단일 목적을 추구합니다.
Profile 클래스가 실세계 개념에 잘 맞는다는 이유만으로 단일 클래스로 한정한다면 피해가 커질 것입니다.
어떤 값을 반환하고 부작용을 발생시키는 (시스템에 있는 어떤 클래스 혹은 엔터티의 상태 변경) 메서드는 명령-질의 분리(command-query separation) 원칙을 위반합니다.
리팩토링으로 인해 단위테스트가 깨지기 시작할 때, 이를 고치기 위한 노력은 단위 테스트를 소유하는 비용에 해당합니다. 단위테스트를 통해 얻을 수 있는 가치가 더 크기 때문에, 받아들여야 하는 비용입니다.
리팩토링은 코드의 동작을 변경하지 않고 코드 구현을 바꾸는 활동입니다. 리팩토링 후 실패하는 테스트의 정도를 부정적인 설계의 지표로 생각해볼 수 있습니다. 더 많은 테스트가 동시에 깨질 수록 더욱더 많은 설계 문제가 있을 수 있습니다.
시스템 설계에 대해 비판적인 눈을 유지하고 최상의 설계는 없다는 것을 명심해야 합니다. 시스템을 깨끗하게 하는 책임은 결코 끝이 없습니다.
실용주의 단위테스트. 10장. 목 객체 사용 (0) | 2021.11.28 |
---|---|
실용주의 단위 테스트. 8장. 깔끔한 코드로 리팩토링하기. (0) | 2021.06.22 |
실용주의 단위 테스트. 7장. 경계 조건: CORRECT 기억법. (0) | 2020.01.01 |
실용주의 단위 테스트. 6장. Right-BICEP: 무엇을 테스트할 것인가? (0) | 2019.11.17 |
실용주의 단위 테스트. 5장. 좋은 테스트의 FIRST 속성. (0) | 2019.11.10 |
댓글 영역