8주차 - 테스트 가능한 설계

[hou27]

⭐ Chapter 8. 테스트 가능한 설계

테스트가 어려운 코드를 상황에 따라 알맞은 방법을 통해 테스트할 수 있도록 하는 방법에 대해 알아본다.

• 테스트가 가능한 설계하는 방법 실습하기
• Chap 8의 내용을 개인 기술 블로그에 정리한 후 자신의 issue에 comment로 링크 남기기
• 문제 만들고, Core Member에게 제출하기(스터디 전날까지 부탁드려요!)

• 모든 과정을 마친 후 pull request 올리기(pr 올릴 변경사항이 없다면 설명을 남긴 후, 체크해주세요)

[hou27]

📚 Chap 8 문제 📚

정리본

X ( 전체 문제 참고 )

Chap 8 전체 문제

<김정호>

Q. 정적 메서드를 사용하는 경우 테스트에 까다로운 이유는 테스트 중 static한 field 또는 method를 사용할 경우 모든 클래스는 예상되는 상태에서 시작되어야하기 때문이다.

A. O

<김연지>

<장채은>

Q. 하드 코딩된 상수를 _**_나 **_****로 받아 테스트가 어려운 코드를 테스트가 가능하도록 설계한다

A. 생성자, 메소드 파라미터

<한규범>

문제 : 외부 라이브러리는 직접 사용하는 것이 테스트 가능한 설계이다.

정답 : X

[hou27]

김정호

문제 및 해설

Q. 정적 메서드를 사용하는 경우 테스트에 까다로운 이유는 테스트 중 static한 field 또는 method를 사용할 경우 모든 클래스는 예상되는 상태에서 시작되어야하기 때문이다.

A. O

테스트 뿐만 아니라 데이터를 가공하거나 특정 메서드를 수행할 때 객체지향적 관점에서 static 사용은 지양해야한다고 합니다.
why-are-static-variables-considered-evil

문제 선정 이유

편하다는 이유로 static을 사용하는 경우가 많은데, static을 사용하면 테스트가 어려워지는 이유를 알 수 있었습니다.

관련 아티클을 읽어보니 static을 사용하면 객체지향적인 관점에서 좋지 않다는 것을 알 수 있었습니다.
이런 정보를 공유하고 싶어서 문제를 선정했습니다.

[Qbeom0925]

한규범

문제 및 해설

Q. 외부 라이브러리는 직접 사용하는 것이 테스트 가능한 설계이다.

A. X
외부 라이브러리 사용하는 경우 감싸서 사용하는 것이 테스트 가능한 설계입니다.
대역으로 대체하기 어려운 외부 라이브러리가 있다면 외부 라이브러리를 직접 사용하지 말고 외부 라이브러리와 연동하기 위한 타입을 따로 만든다. 테스트 대상 코드는 새로 분리한 타입을 사용함으로써 외부 연동으로 필요한 기능을 쉽게 대역으로 대체할 수 있게 됩니다.

문제 선정 이유

프로젝트를 진행하면서 외부에서 불러오는 API에 대한 테스트를 어떤식으로 진행해야할지 알 수 있게 되어 선정하였습니다.

[chaerlo127]

장채은

문제 및 해설

Q. 하드 코딩된 상수를 _**나 ******로 받아 테스트가 어려운 코드를 테스트가 가능하도록 설계한다

A. 생성자, 메소드 파라미터

문제 선정 이유

하드 코딩된 상수(파일 위치 등)로 직접 작성하는 것이 아니라, 다른 개발자들도 사용할 수 있는 형태로 변경하여 작성해야한다는 점을 알게 되었고, 이를 상기시키고자 문제를 선정하게 되었습니다.

[rladuswl]

김연지

문제 및 해설

Q. LocalDate.now() 혹은 Random와 같은 코드에 의해 같은 테스트 코드라도 실행하는 시점에 따라 테스트 결과가 달라진다면 이를 어떻게 해결할 수 있을까?

A. 테스트를 하고자 하는 기능 일부만 별도 기능으로 분리해서 테스트를 진행한다. 또는 테스트하고자 하는 기능 자체를 대역으로 변경하여 '의존 대상 주입'을 한다.
이외의 코드가 올바르게 동작해야 테스트를 하고자 하는 주요 기능의 테스트가 가능하므로 대역 또는 실제 구현 등이 필요하다.

문제 선정 이유

어떻게 하면 테스트가 어려운 코드를 해결할 수 있을지 에 대한 방법을 이해하고 활용할 수 있는 것이 중요하다고 생각했습니다!

[hou27]

[TDD] 7. 테스트 가능한 설계