들어가며

이글은 로버트마틴의 클린코드 9장 Test 단원의 내용을 참고하여 작성하였습니다

오늘은 9장의 일부인 'FIRST 원칙'에 관하여 설명드릴까 합니다 😚


테스트 5가지 원칙 (F, I, R, S, T)

F (Fast 빠르게)
테스트는 빠르게 수행되어야 합니다

각 테스트는 빠르게 수행되어야 합니다.

빠르다의 속도는 상대적일 수 있지만 적어도 통합테스트를 돌리는데 있어서 부담감을 느끼지 않을 정도여야 한다고 생각합니다.

 

우리는 커밋을 하기전에 통합적인 테스트를 수행해봅니다.

하지만, 테스트가 많아지고 각 테스트 마다 소요시간이 오래걸린다면 우리는 배포하는데 어려움을 겪게 됩니다.

 

자바 스프링을 예로 들면 @SpringBootTest와 같이 통합적인 빈을 load하는 것을 지양해야 합니다 (테스트에 필요한 @Bean만 load)

 

I (Independat 독립적으로)
테스트는 독립적으로 수행되어야 합니다

각 테스트는 독립적으로 수행되어야 하며,

A테스트의 결과가 B테스트의 결과의 영향을 미쳐서는 안됩니다

 

다만, 중요한 정책이나 돈이나 자산의 테스트가 이루어져야 하는 케이스라면

@Order 같은 어노테이션을 사용해서 순서를 고정시켜 테스트를 진행하기도 합니다

 

R (Repeatable 반복가능하게)
테스트는 반복적으로 수행해도 결과가 같아야 합니다

테스트는 수정이 발생하지 않는한 매번 결과가 같아야 합니다.

1번 수행하든, 10번 수행하든 성공, 실패의 결과가 매번 동일해야 합니다

 

영화의 티켓값은 성인 기본요금은 10,000 원입니다. 4명의 티켓값은 40,000원 입니다.
티켓값을 계산하는 n번 수행할때마다 티켓값 총합은 매번 40,000 원이 나와야 합니다!!

 

S (Self-Validating 자가검증하는)
테스트는 자체적으로 검증이 가능해야 합니다

각 테스트의 결과는 '성공 또는 실패'여야 합니다

테스트가 스스로 성공과 실패를 가늠하지 않는다면 판단은 주관적이 되며
지루한 수작업 평가가 필요하게 됩니다

 

아래와 같이 결과값을 수동으로 확인하면 안됩니다!!

System.out.println(num);
logger.info(num)

 

Java 진영에서는 JUnit을 이용하면 아래와 같이 결과값을 얻을 수 있습니다

assertThat(num).isEqualTo(expected);

 

T (Timely 적시에)
테스트는 적시에 작성해야 합니다

 단위테스트는 테스트 하려는 실제 코드를 구현하기 직전에 구현해야 합니다

코드를 구현한 다음에 테스트 코드를 만들면 실제 코드가 테스트하기 어렵다는 사실을 발견할지도 모릅니다

이부분의 내용은 테스트주도 개발 (TDD, Test-Driven-Development)과 밀접한 관련이 있습니다

 

TDD 법칙 세가지

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

 

오늘은 테스트의 FIRST 원칙에 대해서 알아보았습니다.

FIRST 원칙과 더불어 TDD의 대한 관심도 많이 증가하고 있는데요,

저는 개인적으로는 TDD보다 우선되어야 할 것이 올바른 테스트 코드 작성 습관이라고 생각합니다.

 

TDD는 사실 개발자에게 높은 수준의 역량을 요구하고 있기에, 

TDD에 앞서 올바른 테스트 코드를 작성하는 것이 중요하다고 생각합니다!! 👻


참조

* 클린코드 - 로버트마틴

'Concept' 카테고리의 다른 글

[test] 테스트코드 작성을 위한 FIRST 원칙 | 클린코드  (0) 2021.10.29
블로그 이미지

yhmane

댓글을 달아 주세요