Post

Clean Code 09장. 단위테스트

Posted
By Eichi
12 min read

TIL(Today I Learn)

2024.07.05


오늘 읽은 범위

9장. 단위 테스트


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

  1. TDD 법칙 세 가지
    첫번째 규칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.
    두번째 규칙: 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다.
    셋번째 규칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.
    이 규칙을 이용하여 실제 코드를 사실상 전부 테스트하는 테스크 케이스를 만들 수 있다.
    하지만 방대한 테스트 케이스는 심각한 관리 문제를 유발할 수 있다.

  2. 깨끗한 테스트 코드 유지하기
    복잡하고 더러운 테스트 코드는 오히려 없는 것이 더 낫다.
    실제 코드에 변경이 발생할 때마다, 복잡하고 더러운 테스트 코드도 변경할 수 밖에 없다.
    테스트 코드가 복잡할 수록 실제 코드를 작성하는 시간보다 테스트 코드를 작성하는 시간이 더 늘어난다.
    즉, 테스트 코드 관리에 대한 부담이 계속 커진다.

  3. 깨끗한 테스트 코드 유지하기2
    신규 버전이 생성될 때마다 테스트 케이스를 유지보수하는 비용이 늘어난다.
    개발자들은 테스트 코드를 불신하게 되고, 모든 일정 지연의 원인을 테스트 코드 탓으로 돌린다.
    하지만 테스트 슈트가 없어지면 개발한 코드가 제대로 동작하는지 확인할 수 없다.
    개발자는 프로그램 변경을 주저하게 되고, 코드는 점점 망가진다.

  4. 깨끗한 테스트 코드 유지하기3
    테스트 코드는 실제 코드 만큼이나 중요하다.
    테스트 코드는 정성들여 작성해야 한다. 실제 코드 못지 않게 깔끔하게 작성해야 한다.

  5. 테스트는 유연성, 유지보수성, 재사용성을 제공한다
    코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목은 바로 단위 테스트다.
    테스트 코드가 있다면 별다른 걱정 없이 프로그램을 변경할 수 있다.
    테스트 코드가 없으면 개발자는 변경을 주저한다. 버그가 발생할 수 있기 때문이다.
    테스트 코드가 지저분하면 구조 개선을 위한 동기부여가 하락한다.
    결국 실제 코드까지 망가진다.

  6. 깨끗한 테스트 코드
    깨끗한 테스트 코드 작성에 제일 중요한 것은 가독성이다.
    테스트 코드의 가독성을 높이려면 명료성, 단순성, 풍부한 표현력이 필요하다.
    테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다.
    BUILD-OPERATE-CHECK 패턴은 테스트 구조에 적합하다.
    BUILD: 부분은 테스트 자료를 만든다.
    OPERATE: 부분은 테스트 자료를 조작한다.
    CHECK: 조작한 결과가 올바른지 확인한다.

  7. 도메인에 특화된 테스트 언어
    도메인에 특화된 언어(DSL)로 테스트 코드를 구현할 수 있다.
    API 위에 함수와 유틸리티를 구현한 후, 이를 이용하여 테스트 코드를 작성한다.
    따라서, 테스트 코드를 작성하거나 읽는 것이 훨씬 쉬워질 것이다.
    잘 작성된 테스트 API는 처음부터 완벽하게 설계된 API는 절대 아니다.
    잡다하고 세세한 사항들로 범벅된 코드를 리팩토링한 결과로 만들어진 API다.
    진정한 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩터링한다.

  8. 이중 표준
    테스트 코드에 적용하는 표준은 실제 코드에 적용하는 표준과는 확실히 다르다.
    테스트 코드는 간결하고, 표현력이 좋아야 하지만 실제 코드만큼 효율적일 필요는 없다.
    실제 환경과 테스트 환경은 요구사항이 확실히 다르다고 할 수 있다.

  9. 테스트 당 assert 하나
    JUnit으로 테스트 코드를 작성할 때는 함수마다 assert 문을 단 하나만 사용하는 장점이 있다.
    assert 문이 단 하나인 함수는 결론이 하나이므로 코드를 이해하기 쉽고 빠르다.
    함수 이름을 변경하여 given-when-then 관례를 사용하는 것이 도움이 된다.
    assert 문을 나누기 위해 테스트 코드를 분리하면 중복되는 코드가 많아진다.
    중복되는 코드가 부담이 된다면, 함수에 assert 문을 여러 개 추가하는 게 나을 수도 있다.

  10. 테스트 당 개념 하나
    “테스트 함수마다 한 개념만 테스트하라”라는 규칙이다.
    독자적인 개념 세 개를 한번에 테스트 하지말고 세 개로 나눠서 검증한다.
    개념을 한 함수로 몰아넣으면 독자가 테스트하는 개념을 모두 이해해야 한다.

  11. F.I.R.S.T
    F(Fast): 테스트는 빠르게 돌아야 한다. 빠르지 않으면 실행부담이 늘어난다.
    I(Independent): 각 테스트는 서로 의존하지 않는다. 각 테스트는 독립적으로 그리고
    어떤 순서로 실행해도 문제가 없어야 한다. 서로에게 의존하면 연쇄적으로 실패한다.
    R(Repeatable): 테스트는 어떤 환경에서도 반복 가능해야 한다. 테스트가 동작하지 않는 환경이
    하나라도 있다면, 테스트가 실패한 이유를 둘러댈 변명이 생긴다.
    S(Self-Validating): 테스트는 부울 값으로 결과를 내야 한다. 성공 아니면 실패다.
    테스트가 스스로 성공 실패를 판단하지 못한다면 지루한 수작업 평가가 동반되어야 한다.
    T(Timely): 테스트는 적시에 작성해야 한다. 단위 테스트는 테스트하려는 실제 코드를 구현하기
    직전에 구현한다. 실제 코드를 먼저 구현하면 테스트 코드를 작성할 엄두를 내지 못할 것이다.

  12. 결론
    깨끗한 테스트 코드는 굉장히 광범위한 주제이다.
    테스트 코드는 실제 코드만큼이나 중요하다. 실제 코드보다 더 중요할 수 있다.
    테스트 코드는 실제 코드의 유연성, 유지보수성, 재사용성을 보존하며 강화할 수 있다.
    테스트 코드의 표현력을 높이고 간결하게 정리한다. 테스트 API를 구현하여 도메인 특화 언어를 만든다.
    테스트 코드가 방지되면 실제 코드도 망가진다. 따라서 테스트 코드를 깨끗하게 유지하자!


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

  • 실제 코드보다 테스트 코드를 먼저 작성하는 것이 중요하다고 생각한다.
    실제 코드를 먼저 작성하면 실제 코드의 로직에 맞추어 테스트 코드를 작성하는 느낌이 있었다.

  • 테스트 코드를 작성하는 방법도 별도의 시간을 투자하여 공부해야 할 것 같다.
    테스트 코드 작성에 대한 지식과 경험이 없다보니 두려움이 앞서 테스트 코드 작성을 기피하게 된다.


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

  • 자바 언어에서 테스트 코드 작성에 도움이 되는 프레임워크는 무엇이 있을까? JUnit 같은 라이브러리가 있지만, 테스트 코드를 일관된 패턴으로 작성할 수는 없는지 궁금하다.


나의 최애 북틸

노마드코더, 클린코드
노개북 노마드코더 개발자북클럽 . . .
This post is licensed under CC BY 4.0 by the author.