slf4j, facade, TDD

pattern

slf4j

• log4j 취약점 사태로 인해 로깅 라이브러리들을 살펴보다가..
• slf4j를 쓰면서 단 한번도 f의 의미에 대해 생각해보지 않음을 깨달음.
• Simple Logging Facade For Java
• facade = 외관, 파사드 패턴의 그 파사드
• 로깅 라이브러리의 인터페이스 역할
• SLF4J가 인터페이스화 되어있기에, SLF4J를 의존하는 클라이언트 코드에서는 실제 구현을 몰라도 됨
•  의존관계 역전 원칙(dependency inversion principle)

 

slf4j, dependency inversion principle

• spring-boot-starter-web > spring-boot-starter-logging에 기본적으로 logback 구현체가 포함되어 있기 때문에 logback을 기본으로 사용

Facade pattern

• 파사드 패턴은 단순화된 인터페이스를 통해서 서브 시스템을 더 쉽게 사용할 수 있도록 하기 위한 용도

whatch movie system

whatchMovie

popper.on();

popper.pop();

lights.dim(10);

screen.down();

projector.on();

projector.setInput(dvd);

projector.wideScreenMode();

amp.on();

amp.setDvd(dvd);

amp.setSurroundSound();

amp.setVolum(5);

dvd.on();

dvd.play(movie);

• 영화를 보기 위해 거쳐야 하는 여러 가지 작업들을 클라이언트는 HomeTheaterFacace를 통해 내부의 복잡한 과정을 몰라도 된다.
• 또한 서브시스템 모듈이 변경되어도 클라이언트에는 영향이 없다.

watch movie fasade pattern

homeTheaterFacade

• HomeTheaterFacace → slf4j
• slf4j.jar Logger interface → facade
• logback.jar Logger class → 구현체

Test Coverage

노련한 개발자는 어떤 상황이 실행 결과에 영향을 줄 수 있는지 찾기 위해 노력한다. 결과에 영향을 줄 수 있는 상황을 고려하지 않고 작성한 코드는 버그를 포함할 가능성이 크기 때문이다. 다양한 예외 상황을 찾아내고 이를 코드에 반영해야 기능이 비정상적으로 동작하는 것을 막을 수 있다. 결과에 영향을 줄 수 있는 모든 상황을 완벽하게 찾기 힘들 수도 있지만 가능한 많은 예외 상황을 찾기 위해 노력해야 한다. 그렇게 함으로써 개발한 소프트웨어의 품질을 높일 수 있다.
테스트주도 개발 시작하기 - p.131

 

갑자기 왜 TDD냐고 할 수 있지만..

'서브시스템 내부에 있는 메서드를 얼마나 많이 테스트했느냐'가 중요하기보다는 

'public interface를 통한 테스트가 얼마나 많은 예외 상황이 테스트되었느냐?'가 더 중요할 수도 있을 것 같다.

왜냐하면 서브시스템의 내부 구현체가 바뀌어도 인터페이스의 예외테스트가 잘 되어 있다면,

변경된 구현체가 테스트케이스를 통해서 요구사항을 잘 충족하고 있는지에 대한 피드백을 받을 수 있다.

오히려 무리하게 서브 시스템 내부의 메서드를 테스트하면 내용결합(content coupling)이 발생하게 된다.

내용 결합

content coupling

• 내용 결합 = 테스트 코드가 시스템 내부의 내용에 대해 지식을 갖게 되는 것
• -> 지식의 의존해 테스트 코드가 작성되면, 운영코드 테스트 코드가 강하게 결합
• -> 어느 한쪽이 변경되면 나머지가 크게 영향받는 구조가 된다.