9장 - 단위 테스트

TDD 법칙 3가지

• 첫째 법칙

  • 실패하는 단위 테스트를 작성할 때 까지 실제 코드를 작성하지 않는다.

• 둘째 법칙

  • 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.

• 셋째 법칙

  • 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

• 실제코드와 맞먹을 정도로 방대한 테스트코드는 심각한 관리문제를 유발하기도 한다.

• 깨끗한 테스트 코드 유지하기

  • 지저분한 테스트코드는 차라리 안하니만 못하다.

  • 코드가 진화하면 테스트코드도 맞춰서 진화해야한다.

  • 코드만진화하고 안바꾸면 나중에 엄청난 부채로 돌아온다

  • 테스트 코드는 실제 코드 못지않게 중요하다

  • 테스트는 유연성, 유지보수성, 재사용성을 제공한다.

    • 코드에 유연성 , 유지보수성, 재사용성을 제공하는것은 바로 단위테스트
    • 테스트코드가 지저분하면 코드를 변경하는 능력이 떨어지며
    • 테스트 코드가 지저분할수록 실제코드도 지저분해진다.
    • 실제 코드도 망가지고 테스트코드도 잃어버린다.

• 깨끗한 테스트 코드

  • 깨끗한 코드를 만들기 위해선 3가지가 필요하다

  • 가독성 , 가독성 , 가독성

  • ( 가독성 개 중요 )

  • 테스트 코드에 가독성을 높이려면 ?

    • 명료성, 단순성, 풍부한 표현력이 필요하다.
    • 테스트 코드는 최소한의 표현으로 많은것을 나타내야 한다.

  • build operate check 패턴

    • 웬지 given when then 느낌나는 패턴임

• 도메인에 특화된 언어

  • 테스트에 특화된 API를 따로 만들어라.

• 이중 표준

  • 테스트 API코드에 적용하는 표준은 실제 코드에 적용하는 표준과 확실히 다르다.
  • 단순하고 간결하고 표현력이 풍부해야 하지만, 실제 코드만큼 효율적일 필요는 없다.
  • 실제 환경에서는 절대로 안되지만 테스트 환경에서는 전혀 문제없는 방식이 있다.
  • 대개 메모리나 CPU 효율과 관련 있는 경우다.
  • 코드의 깨끗함과는 철저히 무관하다

• 테스트당 assert 하나

  • JUNIT으로 테스트 코드를 짤 때는 함수마다 assert문을 단 하나만 사용해야 한다고 주장한 학파가 있다.

  • 장점은 있다.

  • assert문이 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.

  • 만약 어거지로 합쳐서 하나로 만드는 경우가 있다면 차라리 두개로 나눠라

  • 이럴때 중복되는 부분이 있는데 이런것은 템플릿 메소드 패턴을 사용하면

  • 중복을 제거할수 있다.

  • given when 부분을 부모 클래스에 두고 then 부분을 자식클래스에 두면 된다.

  • 아니면 완전히 독자적인 테스트 캘르스를 만들어 @Before 함수에 given when 부분을 넣고 @Test함수에 then부분을 넣어도 된다.

  • 하지만 모두가 배보다 배꼽이 더 크다.

  • 이것저것 감안해보면 결국 assert문을 여럿 사용하는 편이 좋다고 생각한다.

  • 결국 assert문이 여러개 써서 깔끔해진다면 여러개써라

  • 단지 assert문 개수는 최대한 줄여야 좋다는 생각이다.

  • ( 왜냐 이해하기가 쉬워지니까 )

• 테스트당 개념 하나

  • 테스트 함수마다 한 개념만 테스트하라
  • 가장 좋은 규칙은
  • 개념당 assert문 수를 최소로 줄여라 와 테스트 함수 하나는 개념 하나만 테스트하라

• F.I.R.S.T

  • 깨끗한 테스트는 다음 다섯가지 규칙을 가진다.

    • 빠르게

      • 테스트는 빨라야한다. 느리면 자주 돌릴 엄두를 못낸다.
      • 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다.
      • 코드를 마음껏 정리하지도 못한다.

    • 독립적으로

      • 각 테스트는 서로 의존하면 안된다.
      • 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안된다.
      • 테스트가 서로에게 의존하게 되면 하나가 실패할때 나머지도 잇달아 실패하므로 원인을 진단하기 어렵다.

    • 반복가능하게

      • 어떤 환경에서도 테스트는 반복가능해야한다.
      • 그렇지 않으면 환경이 지원되지 않기에 테스트를 수행하지 못하는 상황이 직면한다.

    • 자가검증하는

      • 테스트는 bool 값으로 결과를 내야한다.
      • 성공 아니면 실패다.
      • 통과여부를 알려고 로그파일을 읽게 만들어서는 안된다.

    • 적시에

      • 테스트는 적시에 작성해야 한다.

      • 단위테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.

      • 실제 코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵단

      • 사실을 발견할지도 모른다.

      • 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.

      • ( 결국 테스트를 만들기전에 실제 코드를 만들면 테스트가 불가능하게 설계할수도 있는 상황이 올수도 있다는 것인듯..? )