[노개북] 클린코드 18일차 - 노마드 코더

노마드코더

 

 

 

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

• 이중 표준
  
  • 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다.
    => 대게 메모리나 CPU 효율과 관련 있는 경우다.
    => 코드의 깨끗함과는 철저히 무관하다.
    
    
• 테스트 당 assert 하나
  • assert 문이 단 하나인 함수는 결론이 하나라서 코드를 이해하기 쉽고 빠르다.
  • 독자적인 테스트 클래스를 만들어 @Before 함수에 given/when 부분을 넣고
    @Test 함수에 then 부분을 넣어도 된다.
  • assert 문 개수는 최대한 줄여야 좋다.
    
    
• 테스트 당 개념 하나
  • 테스트 함수마다 한 개념만 테스트하라
  • 이것저것 잡다한 개념을 연속으로 테스트하는 긴 함수는 피한다.
    
    
• F.I.R.S.T
  • 빠르게(Fast)
    => 테스트가 느리면 자주 돌릴 엄두를 못 낸다.
    => 자주 돌리지 않으면 초반에 문제를 찾아내 고치지 못한다.
    
    
  • 독립적으로(Independent)
    => 각 테스트는 서로 의존하면 안 된다.
    => 한 테스트가 다음 테스트가 실행될 환경을 준비해서는 안 된다.
    => 각 테스트는 독립적으로 그리고 어떤 순서로 실행해도 괜찮아야 한다.
    => 테스트가 서로 의존하면 하나가 실패할 때 나머지도 잇달아 실패해 원인을 진단하기 어렵다.
  • 반복 가능하게(Repeatable)
    => 테스트는 어떤 환경에서도 반복 가능해야 한다.(실제 환경, QA 환경, 집에 있는 노트북 등)
    => 테스트가 돌아가지 않는 환경이 하나라도 있다면 테스트가 실패한 이유를 둘러댈 변경이 생긴다.
    
    
  • 자가 검증하는(Self-Validating)
    => 테스트는 부울(bool) 값으로 결과를 내야 한다.(성공 아니면 실패)
    => 통과 여부를 알려고 로그 파일을 읽게 만들어서는 안 된다.
    
    
  • 적시에(Timely)
    => 단위 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현한다.
    => 테스트가 불가능하도록 실제 코드를 설계할지도 모른다.

 

 

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

1. given-when-then이라는 관례를 함수명에 넣은 것은 처음 봤습니다.
   => 제가 작성했던 코드에는 주석을 달아서 명시해줬었습니다.
   => 보통 서비스 로직에 있는 메서드를 가져와서 테스트를 했기 때문에 이 방법을 적용하기 힘들 것 같습니다.
   
   
2. 단위 테스트를 먼저 구현하고 실제 코드를 작성한다는 부분이 흥미로웠습니다.
   => 프로젝트를 하면서 한번 해보고 싶었지만, 같은 팀원이 테스트에 부정적이라 적용이 힘들었습니다.
   => 테스트를 먼저 작성한다면 그것을 어떻게 구상할지 생각해봐야겠다고 생각했습니다.
   => 확실히 이미 구현된 실제 코드를 단위 테스트로 구현하는건 제한 사항이 있었습니다.
       * 코드 커버리지를 올리기 정말 힘들었습니다.

 

 

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

• 테스트를 빨리 돌리는 부분에서 어떻게 해야 할지 감이 안 잡힙니다.
  => 제가 진행했던 프로젝트에서는 규모가 커질수록 테스트가 엄청 오래 걸렸습니다.
  => 좋은 단위 테스트는 속도가 빠르다는 게 이 부분을 개선하도록 해봐야겠습니다.

 

 

👀 소감 3줄 요약

• 테스트 하나 당 개념 하나!
• 테스트는 빠르게 자주 돌릴 수 있도록!
• 모든 환경에서 돌아갈 수 있도록!