클린코드 TIL - 8장 경계, 9장 단위 테스트

오늘 TIL 3줄 요약

• 외부 코드를 우리 코드에 깔끔하게 통합해야 한다.

• give-when-then

• F.I.R.S.T

TIL (Today I Learned) 날짜

2024. 02. 08

오늘 읽은 범위

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

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

외부 코드 사용하기

외부 코드 사용시 캡슐화를 통해 경계 인터페이스가 노출되지 않도록하면 프로그램에 영향을 미치지 않게 할 수 있다.

경계 살피고 익히기

간단한 테스트를 작성하며 외부 코드를 익히는 학습테스트를 통해 통제된 환경에서 API를 제대로 이해하는지 확인하라.

학습 테스트는 API를 사용하려는 목적에 촛점을 둔다.

학습 테스트는 공짜 이상이다.

학습 테스트는 패키지가 예상대로 도는지 검증한다.

학습 테스트는 사용하는 패키지의 신규 버전에 대한 호환성도 밝힐 수 있다.

깨끗한 경계

경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스도 작성한다.

외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. 새로운 클래스로 경계를 감싸거나 ADAPTER 패턴을 사용해 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자.

TDD 법칙 세 가지

1. 실패하는 단위 테스트를 작성할 때까지 실제코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는정도로만 단위 테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

테스트 코드 또한 깨끗한 코드로 유지하지 않으면 테스트 케이스의 유지보수 비용이 늘어난다.

→ TDD의 의미가 퇴색 → 테스트 코드는 실제 코드 못지 않게 중요하다.

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

테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.

깨끗한 테스트 코드를 만들려면? 가독성, 가독성, 가독성

테스트 당 assert 하나

given-when-then 관례 → 테스트 코드를 읽기가 쉬워지지만 테스트를 분리하면 중복되는 코드가 많아 지기도 한다.

→ TEMPLATE METHOD 패턴으로 중복을 제거할 수 있다.

→ given-when을 부모 클래스에 두고 then 부분을 자식 클래스로 둔다.

→ 함수 하나에 단일 assert를 지원하도록 노력하지만 경우에 따라 여러 assert문을 넣기도 한다.

경우의 기준을 어떻게 잡아야 할까?

테스트당 개념하나

테스트 함수마다 한 개념만 테스트하라. → 함수와 동일

깨끗한 테스트를 만드는 5가지 규칙 → F.I.R.S.T

1. Fast 테스트는 빨라야 한다.

2. Independent 각 테스트는 서로 의존하면 안된다. 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다. 테스트의 의존관계는 후반 테스트가 찾아야할 결함을 숨기기도 한다.

3. Repeatable 테스트는 어떤 환경에서도 반복 가능해야 한다.

4. Self-Validating 테스트는 bool 값으로 결과를 내야 한다. (성공/실패)

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

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

외부 패키지 사용시 경계에 대해 생각해 본적이 없었다. 하지만 경계에 대한 개념에 기반한 캡슐화나 인터페이스화는 외부 패키지의 변경에 나의 코드의 의존도를 상당부분 줄일 수 있겠다는 깨달음을 얻었다.

테스트 코드 작성의 중요성을 다시 한 번 되새기게 되었다. 테스트 코드의 작성은 실제 함수를 구현하는 것 이상의 노력과 시간이 필요하다.

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

함수 하나에 단일 assert를 지원하도록 노력하지만 경우에 따라 여러 assert문을 넣기도 한다. → 경우의 기준을 어떻게 잡아야 할까?

오늘 읽은 다른사람의 TIL

• appaaaa님의 TIL (url 링크)