[Clean Code] TIL (2022.03.07) 8장. 경계 ~ 9장. 단위테스트

다시보려고 쓰기·2022년 3월 6일
0

클린코드 (Clean Code)

목록 보기
9/10
post-thumbnail

TIL (Today I Learned)

2022.03.07

오늘 읽은 범위

8장. 경계 ~ 9장. 단위테스트


😃 책에서 기억하고 싶은 내용을 써보세요.


8장. 경계

소프트웨어 경계를 깔끔하게 처리하는 기법과 기교

  • 외부 코드 사용하기
  • 경계 살피고 익히기
  • log4j 익히기
  • 학습 테스트는 공짜 이상이다
  • 아직 존재하지 않는 코드를 사용하기
  • 깨끗한 경계
    (9장 내용이 많아서 8장은 따로 분리할 예정이다.)

9장. 단위테스트

TDD (Test Driven Development) 법칙 세 가지!

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

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


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

지저분한 테스트 코드를 내놓으나 테스트를 안 하나 오십보백보 아니 오히려 더 못하다는 사실
실제 코드가 진화하면 테스트 코드도 변해야 하는데, 테스트 코드가 지저분할수록 어려워진다. 테스트 코드는 실제 못지 않게 깨끗하게 짜야한다. (p.156)

  • 테스트는 유연성, 유지보수성, 재사용성을 제공한다.
    실제 코드를 점검하는 자동화된 단위 테스트 슈트는 설계와 아키텍처를 최대한 깨끗하게 보존하는 열쇠다. 테스트는 유연성, 유지보수성, 재사용성을 제공한다. 테스트 케이스가 있으변 변경이 쉬워지기 때문이다. (p.157)

깨끗한 테스트 코드

깨끗한 테스트 코드를 만들려면 가독성, 가독성, 가독성 세 가지가 필요하다.
가독성을 높이려면, 명료성, 단순성, 풍부한 표현력 이 필요한다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. (p.158)

테스트 코드는 본론에 도입해 진짜 필요한 자료 유형과 함수만 사용한다. (p.161)

  • 도메인에 특화된 테스트 언어
    시스템 조작 API를 사용하는 대신, API 위에 함수와 유틸리티를 구현한 후 그 함수와 유틸리티를 사용 -> 테스트 코드를 짜기도 읽기도 쉬워진다.
    이렇게 구현한 함수와 유틸리티는 테스트 코드에서 사용하는 특수 API가 되는데 이것은 테스트를 구현하는 당사자와 나중에 테스트를 읽어볼 독자를 도와주는 언어가 된다. (p.161)
  • 이중 표준
    테스트 API코드에 적용하는 실제 코드에 적용하는 표준과 다르다. 실제 환경에서는 절대로 안되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 전혀 무관하다. (p.154)

테스트 당 assert 하나

Template Method 패턴을 사용하면 중복을 제거할 수 있다. assert문 개수는 최대한 줄여야 좋다. (p.165)

  • 테스트 당 개념 하나
    == 테스트 함수마다 한 개념만 테스트하라
    이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
    한 테스트에서 여러 개념을 테스트 한다는 것은 문제!
    ➡️ 개념 당 assert 문 수를 최소로 줄여라
    ➡️ 테스트 함수 하나는 개념 하나만 테스트하라
    (p.167)

F.I.R.S.T

  • F ast
    빠르게 - 테스트는 빨리 돌아야한다. 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다.

  • I ndependent
    독립적으로 - 테스트는 서로 의존하면 안되고, 한 테스트가 다음 테스트가 실행될 환경을 준비해서도 안된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
    (p.167)

  • R epeatable
    반복가능하게 - 어떤 환경에서도 반복 가능해야하는데 즉, 어떤 환경에서도 실행할 수 있어야한다.

  • S elf-Validating
    자가검증하는 - 테스트는 부울(bool)값으로 결과를 내야한다. 성공 아니며 실패, 주관X

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

테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하고 강화한다. 테스트 코드는 지속적으로 깨끗하게 관리하자. 표현력을 높이고 간결하게 정리하자. 테스트 API를 구현해 도메인 특화 언어 (DSL : Domain Specific Language)를 만들자. 그리고 테스트 코드를 깨끗하게 유지하자! (p.168)

🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

TDD의 중요성은 정말 많이 들었다. 비록 실천에 옮기지는 못했지만, 앞서 정리한 내용을 토대로 좀 더 TDD랑 친해져야겠다.


🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.


  • Junit - Assert
    Junit : 자바용 단위테스트(Unit Test) 도구
    aseert : JUnit에서 가장 많이 이용되는 단정(assert) 메서드
    단정(assert) 메서드로 테스트 케이스의 수행 결과를 판별할 수 있다.
  • Template Method Pattern -> GOF
    템플릿 메소드 패턴(template method pattern) : 소프트웨어 공학에서 동작 상의 알고리즘의 프로그램 뼈대를 정의하는 행위 디자인 패턴
    GoF (Gang of Fours) Design Patterns: Elements of Reusable Object-Oriented Software. (1995) 에 수록된 23개의 디자인 패턴으로 크게 생성패턴, 구조패턴, 행위패턴이 있다.

참고
JUnit을 이용한 단위 테스트하기+단정(assert)메소드 정리
Javadoc - Assert
Wikipedia - 템플릿 메소드 패턴

0개의 댓글