오늘 TIL 3줄 요약

• TDD 중요하다.

• 한 개념에 하나만 테스트 하자

• 선 테스트 코드 작성, 후 실제 코드 작성으로.

• 테스트 코드는 기도메타(🙏)를 없앤다!

TIL (Today I Learned) 날짜

2022. 03. 06

오늘 읽은 범위

9장. 단위테스트

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

• TDD 법칙 세가지 (p. 155)

  • 첫째 법칙: 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.

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

  • 셋째 법칙: 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

• 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가하는 시간이 더 걸리기 십상이다. (p. 156)

• 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다. 테스트 슈트가 없으면 시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다. (p. 156)

• 테스트 코드는 실제 코드 못지 않게 중요하다. (p. 157)

• 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위 테스트다. (p. 157)

• 테스트 케이스가 있으면 변경이 쉬워지기 때문이다. (p. 157)

• 깨끗한 테스트 코드를 만들려면? 세 가지가 필요하다. 가독성, 가독성, 가독성 (p. 158)

• 테스트 함수마다 한 개념만 테스트하라 (p. 166)

• 규칙은 “개념 당 assert문 수를 최소로 줄여라”와 “테스트 함수 하나는 개념 하나만 테스트 하라”라 하겠다. (p. 167)

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

1. 저는 TDD가 정말 중요하다고 생각한다.
   왜냐면 이전 직장에서는 테스트코드 자체가 없었고 현 직장에서는 테스트 코드를 기반으로 github action을 이용하여 테스트가 통과해야 소스가 적용될 수 있도록 하고 있기 때문에 테스트 코드에 크게 와닫고 있다.
   책에서 소개한 것 처럼 소스 변경의 두려움이 없어진다는 점에 크게 공감이 간다.
   테스트 코드가 없었을 때는 정말 하나 수정하면 다른곳에서 문제가 생기고 운영에서 실행 할때 마다 기도메타(?)를 하며 잘 돌기를 (바보 같이)빌었다.. 🙏
   그러나 지금은 테스트 코드가 있기에 소스 수정에 현재 코드가 망가질 일은 없을 거라 생각 되면서 자신감이 생기고 리팩토링에도 두려움 없이 할 수 있다는 자신감이 생긴다.

2. 테스트 코드 작성은 중요한데 정작 어떤 부분을 테스트 해야하는지, 모든 결과에 대해서 요소마다 체크를 해야하는지에 대해서는 아직도 고민이 많이 된다.
   책에서 처럼 개념당 assert문 수를 최소로 지켜야 한다는 내용을 보고 고쳐나아갔으면 한다.

3. 아직도 잘못된 버릇 중에 하나는 먼저 코드작성을 하고 그것에 맞춘 테스트 코드를 작성한다는 점이다.
   그렇기 때문에 바쁜 일정인 경우 테스트코드는 필수가 아닌 숙제인 마냥 나중에 작성하고 배포부터 해야지.. 라고 생각을 하게 되는데..
   TDD 3가지 법칙 처럼 지켜나아가면서 테스트 코드와 실제 코드가 동시에 만들어 가는 방법을 익히고 배우도록 노력해야겠다는 생각이 들었다.

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

• given-when-then

  • SpecificationByExample을 사용한 시스템 행동방식을 구체화한 테스트를 대표하는 스타일이다.

  • given 파트는 테스트에서 구체화하고자 하는 행동을 시작하기 전에 테스트 상태를 설명하는 부분이다.

  • when 파트는 구체화하고자 하는 그 행동이 된다.

  • then 파트는 어떤 특정한 행동 때문에 발생할거라고 예상되는 변화에 대해 설명하는 부분이다.

오늘 읽은 다른사람의 TIL