노마드코더 개발자북클럽 Clean code TIL 8 : 8-9장. 경계-단위 테스트

오늘 TIL 3줄 요약

프로그램에 필요한 인터페이스만 클래스에서 제공하여
코드를 이해하기 쉽지만 오용하기 어렵게 한라.
실제 코드와 맞먹을 정도로 방대한 테스트 코드는
심각한 관리 문제를 유발하기도 한다.

테스트 함수 하나는, 개념 하나만 테스트하고
개념당 assert 문 수를 최소로 줄여라.
깨끗한 테스트의 다섯 가지 규칙, FIRST

Fast : 테스트는 빨리 돌아야 한다. 빨리 돌아서 자주 실행해야 한다.

Independent : 각 테스트가 서로 의존하면 안 된다.

Repeatable : 테스트는 어떤 환경에서도 반복 가능해야 한다.
테스트가 돌아가지 않는 환경이 하나라도 있다면
(QA, Production, Test, local development 등)
실패의 변명이 생긴다.

Self-validating : 부울 값으로 결과를 내야 한다.
성공 아니면 실패다.
텍스트 or 로그 파일에 따로 만들어서 결과를 비교하지 않는다.

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

TIL (Today I Learned) 날짜

2025. 06.06

오늘 읽은 범위

8장 경계

9장 단위 테스트

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

경계에 위치하는 코드는 깔끔히 분리한다.
기대치를 정의하는 테스트 케이스를 작성한다.
테스트 케이스를 모두 구현하고
통과한 후에는 내 코드를 사용할 사람들에게 공개한다.
테스트 코드와 내 코드를
같은 소스 패키지로 확실하게 묶어 체크인 한다.
테스트 슈트(Test suite)가 없으면 결함율이 높아진다.
테스트 코드는 실제 코드만큼이나 프로젝트 건강에 중요하다.
때문에, 테스트 코드는 지속적으로 깨끗하게 관리하자.
깨끗한 테스트 코드는
첫째는 가독성,
둘째도 가독성,
셋째 또한 가독성이다.
이중 표준의 본질
실제 환경에서는 절대 안 되지만,
테스트 환경에서는 전혀 문제없는 방식이 있다.

머신의 메모리나 cpu스펙 차이는
코드의 깨끗함과는 철저히 무관하다.
테스트 케이스가 없으면 개발자는 버그에 대한 두려움 때문에 변경을 주저한다.
테스트 케이스가 있다면 공로는 사라진다.
테스트 커버리지가 높을수록 공포는 줄어든다.

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

적시에 테스트 코드를 작성하지 않고
개발 일정에 쫓겨 선 개발, 후 테스트를 하는 일이 빈번했다.

테스트는 나에게 있어서 '여유가 있을 때 작성하는' 코드 정도였는데
깊이 반성하며, 다시 습관을 제대로 잡아야겠다.
Build-Operate-Check 패턴
테스트에도 패턴이 있는 줄 몰랐다.

테스트 자료를 만들고
테스트 자료를 조작하고
조작한 결과가 올바른 지 확인한다.

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

Adapter pattern이 뭘까?
Adapter pattern을 사용하면
우리가 원하는 인터페이스를
패키지가 제공하는 인터페이스로 변환이 가능하다.
Transmitter의 예시에서 TransmitterAdapter는 어떻게 간극을 메우는가?

나의 최애 TIL

Effective java를 읽은 내용을 바탕으로
java의 배경 지식과 맥락을 보충 설명해주셔서
좀 더 깊이있게 학습하기 좋았습니다.

소감이 인상 깊었고 반성할 수 있었습니다.

소감이 공감됐고
조만간 테스트 슈트를 만드는 것을 TIL로 매일매일 갱신해야겠습니다.

Computation suite