5장 목과 테스트 취약성 (3)

단위테스트 (블라디미르 코리코프)

5장 목과 테스트 취약성 (1)

5장 목과 테스트 취약성 (2)

에서 이어지는 글입니다.

---

2. 식별할 수 있는 동작과 구현 세부 사항

테스트에 거짓 양성이 있는 (리팩터링 내성에 실패하는) 주요 이유는 코드의 구현 세부 사항과 결합돼 있기 때문이다.

이러한 강 결합을 피하기 위해서는 최종 결과(식별할 수 있는 동작)를 검증하고 구현 세부 사항과 테스트를 가능한 한 떨어뜨려야 한다.

테스트는 “어떻게”가 아니라 “무엇”에 중점을 둬야한다.

 

2.1 식별할 수 있는 동작은 공개 API와 다르다

모든 제품 코드는 2차원으로 분류할 수 있다.
- 공개 API 또는 비공개 API
- 식별할 수 있는 동작 또는 구현 세부 사항

 

코드의 공개성은 private, public, internal 키워드 등 접근 제한자에 의해 제어된다.

 

코드가 시스템의 식별할 수 있는 동작이려면 다음 중 하나를 해야 한다.
- 클라이언트가 목표를 달성하는 데 도움이 되는 연산(operation)을 노출하라. 연산은 계산을 수행하거나 사이드 이펙트를 초래하거나 둘 다 하는 메서드다.
- 클라이언트가 목표를 달성하는 데 도움이 되는 상태(state)를 노출하라. 상태는 시스템의 현재 상태다.
구현 세부 사항은 이 두 가지 중 아무것도 하지 않는다.

 

코드가 식별할 수 있는 동작인지 여부는 해당 클라이언트가 누구인지, 그리고 해당 클라이언트의 목표가 무엇인지에 달려 있다.

정리해보면

클라이언트는 굳이 세부사항은 알 필요가 없다. 이러한 부분들이 구현 세부 사항이 된다.
클라이언트가 알아야 하는 부분들, 클라이언트의 입장에서 기능이라고 할 수 있는 것들이 식별할 수 있는 동작 이 된다.

코드의 공개성은 실제 코드의 접근 제한자를 통해 결정되는 부분이다.
그리고 이 두가지가 일치할 때 이상적인 시스템 API 설계라고 할 수 있다.

잘 설계된 API의 상태 - 식별할 수 있는 동작과 공개 API가 일치하며, 구현 세부 사항과 비공개 API가 일치함.

 

공개 API가 식별할 수 있는 동작의 범위를 넘어서면 시스템은 구현 세부 사항을 유출한다.

 

2.2 구현 세부 사항 유출: 연산의 예

생략

 

2.3 잘 설계된 API와 캡슐화

잘 설계된 API를 유지 보수하는 것은 캡슐화 개념과 관련이 있다.
캡슐화는 불변성 위반이라고도 하는 모순을 방지하는 조치다.
불변성은 항상 참이여야 하는 조건이다.

 

구현 세부 사항 노출은 불변성 위반을 가져온다.
구현 세부 사항을 숨기면 클라이언트의 시야에서 클래스 내부를 가릴 수 있기 때문에 내부를 손상시킬 위험이 적다.

 

데이터와 연산을 결합하면 해당 연산이 클래스의 불변성을 위반하지 않도록 할 수 있다.

 

2.4 구현 세부 사항 유출: 상태의 예

생략

 

2.5 요약

	식별할 수 있는 동작	구현 세부 사항
공개	좋음	나쁨
비공개	해당 없음	좋음

 

참고

묻지 말고 말하라(TellDontAsk) - 마틴 파울러

 

원문 : https://martinfowler.com/bliki/TellDontAsk.html

번역 : https://m.blog.naver.com/sorang226/221796702354