TIL (Today I Learned) 날짜

2022. 05. 08

오늘 읽은 범위

9장. 단위 테스트

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

- TDD 법칙 세가지: 1. 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. / 2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. / 3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

- 테스트 코드는 실제 코드 못지 않게 중요하다. 테스트 코드는 사고와 설계와 주의가 필요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다.

- 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다.

- 가독성은 실제 코드보다 테스트 코드에 더더욱 중요하다.

- 테스트 코드는 본론에 돌입해 진짜 필요한 자료 유형과 함수만 사용한다. 그러므로 코드를 읽는 사람은 온갖 잡다하고 세세한 코드에 주눅들고 햇갈릴 필요 없이 코드가 수행하는 기능을 재빨리 이해한다.

- 실제 환경에서는 절대로 안 되지만 테스트 환경에서는 전혀 문제없는 방식이 있다. 대개 메모리나 CPU 효율과 관련 있는 경우다. 코드의 깨끗함과는 철저히 무관하다.

- 대체로 나는 단일 assert를 지원하는 해당 분야 테스트 언어를 만들려 노력한다. 하지만 때로는 주저 없이 함수 하나에 여러 assert 문을 넣기도 한다. 단지 assert 문 개수는 최대한 줄여야 좋다는 생각이다.

- 어쩌면 '테스트 함수마다 한 개념만 테스트하라'는 규칙이 더 낫겠다.

- 가장 좋은 규칙은 '개념 당 assert 문 수를 최소로 줄여라'와 '테스트 함수 하나는 개념 하나만 테스트하라'라 하겠다.

- F.I.R.S.T: Fast(빠르게) / Independent(독립적으로) / Repeatable(반복가능하게) / Self-Validating(자가검증하는) / Timely(적시에)

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

- 코딩 시 단위테스트 해야지 하는 생각은 항상 있지만, 바쁜다는 핑계로 넘어가곤 한다.

- 그리고 실제 코드 구현 후 테스트가 필요할 시 부랴부랴 단위테스트 만들고 한다. 또한 일회성으로 끝나곤 한다.

- 이번 챕터에서는 TDD 중요성과 실제 코드 처럼 가독성이 중요하다는 핵심을 말하고 있다.

- 실제 코드 작성 시 단위테스트 먼저 구현하는 습관을 항상 들여야 겠다.