클린코드 9장 단위 테스트

노션에서 정리한 내용을 벨로그로 옮겼기 때문에 노션으로 보면 조금 더 보기 더 편합니다🤗

이동하기 → junnkk's Notion

제대로 된 테스트 케이스를 작성해야 한다.

TDD 법칙 세 가지

• TDD : Test Driven Development의 약자로 테스트 주도 개발이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

참고

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

→ 세 가지 규칙을 따를 시 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나오며 테스트 코드가 실제 코드보다 불과 몇 초전에 나온다.

⇒ 코드의 양 ↑

but 너무 방대한 양의 테스트 코드는 심각한 관리 문제 유발하므로 관리 중요

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

테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 사고와 설계와 주의가 필요.

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

  • 단위 테스트(unit test) : 말 그대로 한 단위(일반적으로 class)만을 테스트 하는 것

    → 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목( ∵ 테스트 케이스가 있으면 변경이 쉬워짐)

    • 실제 코드를 점검하는 자동화된 단위케이스 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존시킨다.

• 참고

  테스트 커버리지 : 시스템 소프트웨어의 논리적 구조가 test suite에 의해 테스트된 정도. 테스트의 충분함을 측정

  테스트 슈트 : 일정한 순서에 의하여 수행될 개별 테스트들의 집합, 또는 패키지. 슈트는 응용 분야나 우선순위, 내용에 연관된다.

깨끗한 테스트 코드

• 깨끗한 테스트 코드를 위한 필수적인 요소 : 가독성

  • 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요(최소한의 표현으로 많은 것 나타내야 함.)

    예시)

    p160~161 [9-1] 중복되는 코드가 많은 세 개의 테스트 케이스

    → 테스트와 무관한 코드 多 ex)pagePath 객체, responder, response 관련 코드 등

    p160 [9-2] 9-1을 리팩터링한 코드

    → 테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용

    → BUILD-OPERATE-CHECK 패턴 적합

  • 가독성을 늘리기에 좋다.

    BUILD : 테스트 자료를 만든다.
    OPERATE : 테스트 자료를 조작한다.
    CHECK : 조작한 결과를 확인한다.

• ❓도메인에 특화된 테스트 언어(DSL)

  • 9-2 흔히 쓰는 시스템 조작 API를 사용하는 대신 API 위에다 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용하므로 테스트 코드를 짜기도 읽기도 쉬워짐.

    → 이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 됨. (즉, 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 테스트 언어이다)

  • 이러한 테스트 API는 처음부터 설계된 API가 아님. 계속 리팩터링하다가 진화된 API

• 이중 표준

  • 테스트 API에 적용하는 표준(≠ 실제 코드에 적용하는 표준)

    → 테스트 코드는 단순, 간결, 표현력 풍부해야 함 but 실제 코드만큼 효율적일 필요 X

    → 실제 환경과 요구 사항 다름

    예시) p162~163 [9-3] → [9-4]로 리펙터링 ∵ 가독성 떨어지므로

  • 이중 표준의 본질

    테스트 환경: 컴퓨터 자원이 제한적일 가능성 ↓ ↔ 실제 환경: 자원과 메모리가 제한적일 가능성 ↑

    ⇒ 실제 환경에서는 절대로 안되지만 테스트 환경에서는 전혀 문제 없는 방식이 있음(대게 메모리나 CPU 효율 관련. 코드의 깨끗함과 무관)

테스트 당 assert 하나

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

  예시) p164~165 [9-2]→[9-7] 함수 이름을 바꿔 given-when-then 사용

  → 테스트를 두 개로 쪼개 각각 assert 수행으로 가독성 ↑ but 중복 코드 ↑

• TEMPLATE METHOD 패턴 사용 시 중복 제거 가능

  방법 1. given/when 부분을 부모 클래스에 두고 then 부분을 자식 클래스에 둠

  방법 2. 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when 부분을 넣고 @Test 부분에 then 부분을 넣음

  ⇒ but 9-2 처럼 assert 문 여럿 사용하는 편이 더 좋다

∴ 종합하면 '단일 assert 문' 은 좋지만 필요 시 추가. 적을 수록 좋다.

• 테스트 당 개념 하나

  ⇒ 테스트 함수마다 개념 하나만 테스트 하라.

  ∵ 여러 개념이 한 함수에 존재할 때 독자가 각각이 존재하는 이유와 각 절이 테스트하는 개념을 모두 이해해야 하기 때문

즉 개념 당 assert 문 수를 최소로 줄이고 테스트 함수 하나는 개념 하나만 테스트 해야 한다

F.I.R.S.T

깨끗한 테스트가 따르는 다섯 가지 규칙

Fast 빠르게

→ 테스트는 빨리 돌아야 한다. 자주 돌려서 초반에 문제를 찾아내서 고치고 코드를 정리해야 함.

Independent 독립적으로

→ 각 테스트는 의존하면 안 된다. 한 테스트가 다음 테스트가 실행될 환경을 준비하면 X. 독립적, 순서 상관 X

Repeatable 반복가능하게

→ 어떤 환경에서도 반복 가능해야 함.

Self-Valiading 자가검증하는

→ 테스트는 bool 값으로 결과 내야 함.

Timely 적시에

→ 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현.

결론

테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화하므로 지속적으로 깨끗하게, 표현력 높게, 간결하게 정리해야 한다.

테스트 API를 구현해 도메인 특화 언어(DSL)를 만들어야 한다.

→ 10장 클래스