클린코드 챌린지 Day 14, 15

seul·2024년 2월 9일

개발자북클럽

목록 보기

9/11

📅 TIL (Today I Learned): 2024.02.09
📋 오늘 읽은 범위: 8. 경계, 9. 단위 테스트

😎 책에서 기억하고 싶은 내용을 써보세요.

모든 소프트웨어를 직접 개발하는 경우는 드물기에 때로는 패키지를 사거나 오픈 소스를 이용하게 되는데, 이때 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. -> 소프트웨어 경계를 깔끔하게 처리하기

프레임워크 제공자는 '적용성을 최대한 넓히려' 하고, 사용자는 '자신의 요구에 집중하는 인터페이스'를 바란다.

이건 코드로 담아야겠다...

Map은 굉장히 많은 역할을 하고 있는데 clear() 기능도 가능하다는 것! 근데,

Map sensors = new HashMap();
Sensor s = (Sensor)sensors.get(sensorId);

이렇게 하면 Map이 반환하는 Object를 알맞게 변환할 책임을 클라이언트가 갖게 된다.

그래서 Generics을 사용하면 코드 가독성이 높아지긴 하는데,

Map<String, Sensor> sensors = new HashMap<Sensor>();
Sensor s = sensors.get(sensorId);

이렇게 해도 Map<String,Sensor>가 필요하지 않은 기능까지 제공하게 된다.

그래서

public class Sensors {
	private Map sensors = new HashMap();
}

경계 인터페이스인 Map을 Sensors 안으로 숨긴다.
이렇게 하면 나머지 프로그램에는 영향을 미치지도 않고, 필요한 인터페이스만 제공할 수 있다.

경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.
Map 인스턴슬르 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.

우리 쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것

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

맞는 얘긴데 때로는 주저 없이 함수 하나에 여러 assert 문을 넣기도 한다.
그래서,
'개념 당 assert 문 수를 최소로 줄여라'와 '테스트 함수 하나는 개념 하나만 테스트하라'로 말할 수 있겠다.

First, 빠르게: 테스트는 빨라야 한다. 느리면 자주 못 돌리는데 그러면 초반에 문제를 찾아내 고치지 못 한다.
Independent, 독립적으로: 각 테스틑 서로 의존하면 안 된다.
Repeatable, 반복 가능하게: 테스트는 어떤 환경에서도 반복 가능해야 한다.
Self-Validation, 자가검증하는: 테스트는 bool 값으로 결과를 내야 한다. 성공 아니면 실패핟. 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다.
Timely, 적시에: 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트 하려는 실제 코드를 구현하기 직전에 구현한다.