Clean Code 읽기(3)

9장 단위 테스트

• TDD 법칙 세 가지

  1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
  2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
  3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

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

  실제 코드가 진화할수록 테스트 코드도 변해야한다. 테스트 코드가 지저분할 수록 변경하기 어려워진다. 깨끗한 단위 테스트 코드는 실제 코드 못지않게 매우 중요하다.

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

    코드에 유연성 유지보수성 재사용성을 제공하는 버팀목이 단위테스트이다. 따라서 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다.

• 깨끗한 테스트 코드

  깨끗한 코드 == 가독성 가독성 가독성!!, 명료하고 단순하고 풍부한 표현력

  이해는 되는데 좀 어렵.. 실제로 어떻게 해야하는지 감이 잘 안옴

  코드 리팩토링하는 과정, 확실히 가독성이 좋다 잡음 코드들, 공통 코드를 하나로

  build-operate-check 패턴 – 세 부분으로 나눔, 테스트 자료 생성, 테스트 자료 조작, 테스트 자료 결과 확인

  • 도메인에 특화된 테스트 언어

    도메인에 특화된 언어 DSL : 관련 특정 분야에 최적화된 프로그래밍 언어.

    더 알아보기, 검색해보니 다양한 얘기가 나오긴한다.

  • 이중 표준

    실제코드만큼 효율적일 필요가 없다? 실제 환경에서는 안되지만 테스트환경에서는 문제없는 방식?

    이 파트에서 설명하는게 무슨말인지 잘 모르겠다.

• 테스트 당 assert 하나

  assert가 하나라면 명확히 결론이 하나라서 이해하기 쉽다. 물론 여러 assert문이 들어갈 수 있으나 최대한 줄이는게 좋다. 9-5 예시를 보니까 확실히 하나인게 이해가 더 잘된다,

  여기서도 given - when - then 패턴이 등장한다.

  given - when - then

  • 테스트 당 개념 하나

    9-8 예시는 하나의 test메소드에 여러 개념을 테스트하고있다. 한 테스트 메소드당 하나의 결과를 낼 수 있도록 테스트하는 것이 바람직하다.

• F.I.R.S.T.

  Fast, Independent, Repeatable, Self-Validating, Timely

  독립적이라고 한거는 Test만 그러는걸까? 실제 구현 메소드에서는 메소드 A에서 메소드 B를 호출하고 B에서 C를 호출하고 계속 … 그런 의존성은 크게 문제가되지않을까?

  빠르고, 테스트끼리 서로 의존X, 어떠한 환경에서도 반복가능, true/false로 명확하게 검증(나처럼 로그확인하고 그러는거 좋지않다), 선테스트 후실제코드

• 결론

  테스트 코드가 중요하다라는건 머리로 알겠다. 그 태형이형이 보여준것도 이해는되고.. 근데 실제로 테스트코드를 먼저 짜려고하면 어려움을느낀다 계속 연습이 필요한거같은..?