[ 박우빈 Practical Testing #3 ] 더 나은 테스트를 작성하기 위한 Tip (4)

① 한 문단에 한 주제
② 완벽하게 제어하기
③ 테스트 환경의 독립성을 보장하자.
④ 테스트 간 독립성을 보장하자.
⑤ 한 눈에 들어오는 Test Fixture 구성하기
⑥ Test Fixture 클렌징
⑦ 테스트 수행도 비용이다. 환경 통합하기
⑧ private 메서드의 테스트
⑨ 테스트에서 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없는 경우

---

⑦ 테스트 수행도 비용이다. 환경 통합하기

• 전체 테스트를 수행할 때 마다 서버가 뜨는 횟수가 많아진다면, 전체 테스트 수행시간이 길어지게 된다. (테스트 수가 많을수록, 테스트 환경이 바뀔수록, 서버가 뜨는 횟수가 많아질 것이고 그렇게 되면 전체 테스트시 수행 비용이 늘어나게 된다. )
• 그러면 어떻게 하면 더 빠른 시간안에 효과적으로 테스트를 수행할 수 있을까?
  • 동일한 환경에서 테스트들이 수행될 수 있도록 공통적인 환경들을 모아주면 서버가 새로 뜨는 횟수를 줄일 수 있다.
    
    • 공통적인 환경을 통합해서 서버가 뜨는 횟수를 줄이는 게 좋다.

 

⑧ private 메서드의 테스트

• private 메서드를 억지로 테스트 하려고 할 필요는 없다. 왜냐하면 어차피 객체의 공개 메서드를 테스트 하다보면, 자연스럽게 검증되기 때문이다.
• 그럼에도 불구하고 private 메서드를 테스트하고 싶다면, 또는 해야할 것 같다면, 그 시점에 이런 고민을 해볼 필요가 있다.
  • 객체를 분리할 시점인가?
    • 객체 분리의 신호로 볼 필요가 있는 것이다. 따라서 하나의 공개 메서드 안에서 하는 일이 너무 많나? 등에 대한 의문도 던져보는 게 좋다.
    • 그게 맞다는 생각이 든다면, 별도의 객체를 생성해서 private 에서 하던 기능을 그 객체가 수행하도록 위임하고, 테스트도 단독으로 수행할 수 있도록 하는게 좋다.

 

⑨ 테스트에서 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없는 경우

• 만들어도 된다. 하지만 보수적으로 접근하자.
  • 기본적으로는 테스트에서만 사용되는 메서드를 프로덕션 코드에 막 만들어내는 것은 지양하는게 좋다.
  • 하지만 경우에 따라 테스트에서는 필요한데 프로덕션 코드에서는 사용하지 않는 메서드들이 필요할 수 있다. (ex. getter, 기본생성자, builder 등 )
  • 그런 경우, 해당 메서드의 성격이 (어떤 객체가 마땅히 가져도 되는 행위 + 미래에도 충분히 사용될 수있는 성격)의 메서드라면 만들어도 된다고 본다.
    • 물론 만들지 않고 해결할 수 있다면 best 이다.

---

강의를 듣고 정리한 글입니다. 코드와 그림 등의 출처는 박우빈 강사님께 있습니다.