[루비로 배우는 객체지향 디자인] 09. 비용 - 효율적인 테스트 디자인하기

• 테스트를 처음 작성하는 프로그래머가 테스트를 통해 얻는 이익보다 테스트를 작성하는 데 들이는 비용이 분명 더 클 때 이들은 매우 불편한 상황에 놓인다. 🥲
• 만약 이 책을 읽는 독자가 초보 디자이너이고 이런 상황에 처해 있다면 테스트의 가치를 계속 믿는 것이 중요하다.
• 테스트가 없다면 이해할 수도 없고 안전하게 수정할 수도 없을 것이다.
• 최상의 테스트는 실제 코드와 느슨하게 결합되어 있어야 한다. 그리고 모든 코드를 한 번만, 제대로 된 장소에서 테스트해야 한다.

• 수정하기 쉬운 코드를 작성하는 일에는 3가지 기술이 필요하다.

  • 객체지향 디자인 이해

    • 실용적인 관점에서 디자인이 고려해야 하는 것은 손쉬운 수정가능성 뿐이다.

  • 훌륭한 리팩터링 기술

    • 코드의 외적인 작동방식을 변경하지 않으면서 내부 구조를 발전시키는 것
    • 좋은 디자인은 최소 비용으로도 애플리케이션이 최대한 유연하 형태로 남아 있을 수 있게 해준다.

  • 효율적인 테스트 코드

    • 효율적인 테스트는 수정된 코드가 별 문제없이 잘 작동해 준다고 보증해준다.

의도를 가지고 테스트하기

• 테스트의 목표

  • 코드 작성 비용을 줄이는 것
• 테스트 코드를 작성하고 관리하고 실행하는 시간 > 버그를 잡고 문서를 작성하고 테스트 코드를 디자인 하는데 걸리는 시간 -> 테스트를 작성하는 의미가 없다.
• 테스트 작성 비용이 너무 높은 문제를 해결하기 위한 방법은 테스트를 그만두는 것이 아니라 테스트를 더 잘 짤수 있도록 수련하는 것이다. 🥲

• 테스트의 의도

  • 버그를 초기에 찾아내기
  • 문서 제공

  • 디자인 결정 미루기

    • 테스트가 인터페이스에 기대고 있다면 인터페이스 밑에 숨겨진 구체적인 코드는 나중에 마음껏 리팩터링 할 수 있다.
    • 테스트는 인터페이스가 계속해서 올바르게 작동하고 있다는 점을 확인해 줄 수 있고 리팩터링 과정에서 테스트를 다시 작성할 필요도 없다.

  • 추상화를 돕기

    • 테스트는 모든 추상화된 인터페이스의 기록이기 때문에 우리의 작업을 지지해주는 기반이 된다. 테스트는 우리가 디자인 결정 미루고 필요한 만큼 추상화된 코드를 만들 수 있도록 해준다.

  • 디자인 결점 드러내기

    • 테스트를 작성하기 위한 준비 작업이 너무 힘겹다면 코드에 너무 많은 맥락이 있나는 뜻
    • 객체 하나를 테스트하기 위해 다른 객체를 왕창 끌어와야 한다면 이 코드는 의존성이 높다는 뜻이다.
    • 하지만 테스트가 힘들다고 해서 애플리케이션의 디자인에 반드시 문제가 있는 것은 아니다.

• 무엇을 테스트할 것인가?

  • 테스트에서 더 나은 가치를 얻기 위해서는 모든 것을 단 한번만 테스트하고 제대로 된 곳에서 테스트해야 한다.

  • 우리가 테스트 해야 하는 것은 퍼블릭 인터페이스에서 정의된 메시지다.

    • 테스트는 테스트 중인 객체가 바깥 세계와 어떻게 상호작용 하는지 이야기 해준다.
    • 들어오는 메시지에 대해서는 메시지가 반환하는 상태를 테스트한다.
    • 밖으로 나가는 커맨드 메시지에 대해서는 이 메시지가 제대로 전송되었는지 테스트해야 한다.

  • 가장 비효율적이고 불필요한 테스트는 객체 내부의 불안정한 세부사항을 테스트 하는 것 -> 프라이빗 메서드 테스트

    • 프라이빗 메서드를 테스트 하지 말아야 하는 이유

      • 프라이빗 메서드에 버그가 있다면 당연히 전체 애플리케이션 전체에 문제가 생기겠지만, 이 문제는 다른 테스트를 통해 찾을 수 있다.
      • 프라이빗 메서드는 불안정하다. -> 프라이빗 메서드에 대한 테스트는 변경될 확률이 높은 애플리케이션 코드에 결합되어 있다.
  • 테스트는 객체의 경계를 넘나드는 메시지에 집중해야 한다.

• 언제 테스트할 것인가?

  • 테스트를 먼저 작성할 수 있는 상황🥲이라면 먼저 작성하는 것이 좋다.

    • 테스트를 먼저 작성하면 객체를 처음 만드는 순간부터 객체 속에 약간의 재사용 가능성으로 각인시켜 놓게 된다.
    • 하지만 테스트를 먼저 작성하는 것만으로 제대로 디자인된 애플리케이션이 완성되는 것은 아니다.

• 어떻게 테스트할 것인가?

  • 테스트 주도 개발(TDD)

    • 테스트가 개발 전에 작성되어야 한다.
    • 안에서 밖으로 나가는 접근을 취한다.

  • 행동 주도 개발(BDD)

    • BDD는 밖에서 안으로 들어오는 접근을 취한다.
    • 비즈니스 요구사항이나 사용자의 행동에 대한 스토리를 기반으로 작성하는 방식
    • 가장 바깥쪽에 있는 객체들을 먼저 만들고 당장 필요하지만 아직 만들지 않은 객체들은 임시로 만들면서 점점 안쪽으로 들어온다.

들어오는 메시지 테스트하기

• 들어오는 메시지들은 객체의 퍼블릭 인터페이스를 형성한다.

• 사용하지 않는 인터페이스 찾기

  • 들어오는 메시지가 딸린 객체를 가지고 있지 않다면 사실은 들어오는 메시지가 아닐 수 있기 때문에 의심해 보아야 한다.

• 메시지 내에서 사용되는 다른 객체에 대한 의존

  • 다른 객체에 은밀하게 의존할 경우 테스트 비용이 높아진다.
  • 역할에 대한 의존성 주입 -> 코드를 수정하지 않고도 구체 클래스들을 서로 대체해서 사용하기 위함.

  • 테스트 더블(가짜 객체) 만들어서 주입

    • 테스트 더블은 역할을 수행하는 객체의 표준적인 형태

      • 테스트 더블을 사용하면 실제 애플리케이션에서는 실패하지만 테스트에서는 정상적으로 동작하는 상황을 만들 수 있다.

        • 테스트 더블이 필요한 퍼블릭 인터페이스를 구성하고 있는지 인터페이스에 대한 테스트로 검증할 필요가 있다.
        • 주어진 역할을 제대로 수행하는지 검증해 주면 위태롭지 않은 테스트를 작성할 수 있다. 또한 스텁의 부정적인 결과를 피할 수 있다.
    • 역할을 문서화하기 위한 도구로 테스트 코드 사용하기
• 테스트를 작성하는 것만드로 디자인이 좋아지는 것은 아니다 -> 결합도를 줄이는 것은 프로그래머의 손에 달려 있고, 프로그래머가 디자인의 원칙을 얼마나 잘 이해하고 있는가와 연관된 문제이다.

밖으로 나가는 메시지 테스트하기

• 밖으로 나가는 쿼리 메시지는 무시한다. -> 메시지가 정상적으로 작동하는지 테스트 하는 것은 메시지를 구현하고 있는 객체의 책임.
• 애플리케이션의 다른 부분이 이 메시지의 전송의 결과에 의존하고 있는 경우 -> 테스트 중인 객체가 이 메시지를 전송해야 할 책임을 가지고 있다. 그리고 실제 전송 여부를 테스트해야 한다.

• mock

  • 행동에 대한 테스트
  • 메시지가 무엇을 반환하는지를 검증하는 대신, 목 객체가 어떤 메시지를 수신하기를 원하는지를 테스트 한다.

• 잘 디자인된 애플리케이션의 경우, 밖으로 나가는 메시지는 간단히 테스트할 수 있다.

  • 적극적으로 의존성 주입 기술을 사용했다면, 주입된 객체를 손쉽게 목 객체로 대체할 수 있다.

상속 받은 코드 테스트하기

• 상속 받은 코드의 테스트 목표

  • 상속 관계에 속한 모든 객체들이 약속을 제대로 이행하고 있는지 검증하는 것

    • 상속 관계 속의 모든 객체가 리스코프 원칙을 잘 따르고 있는지 검증하는 가장 쉬운 방법은 공통의 약속을 테스트하는 공용 코드를 작성하고 이 테스트를 모든 객체에 인클루드하는 것이다.
• 신중하게 작성된 상속 관계는 테스트하기 쉽다. -> 전체적인 인터페이스에 대한 테스트 코드를 하나 작성해서 공유하고, 이어서 하위클래스의 책임을 테스트하면 된다.