Facts (사실, 객관)

  1. 5주차 과제 마무리 (완전 끝은 아니지만 거의 다 한듯)
  2. 테스트 주도 개발 2부(XUnit) 공부 및 실습 마무리
  3. 테스트 주도 개발 3부 26장까지 읽기

Feelings (느낌, 주관)

  1. 테스트 코드 작성능력이 많이 늘었다고 느껴진다.
  2. 테스트 주도 개발도 계속 연습하니 많이 자연스러워졌고, 실제로 그 효과를 느끼고 있다.

Findings (배운 점)

요즘 테스트 주도 개발을 하면서 여러가지 느낀 점이나 배운 점들이 있는데, 이를 언어로 표현하기가 어려운 것 같다. 그런데 테스트 주도 개발 책 3부를 읽다보니 이런 것들이 잘 표현되어있는 것 같아서 책 내용을 인용하면서 내 생각도 간단히 적겠다.

  1. 당신이 변화를 테스트할 수 있다고 해도, 실제로 변화를 테스트하는 것은 테스트를 갖고 있다는 것과 똑같지 않다.
  2. 테스트를 갖고 있다는 것은 자동화된 테스트가 존재함을 의미한다. 이것은 단순히 변화를 테스트해볼 수 있는 것과 완전히 다르다. 피드백을 훨씬 빠르게, 그리고 자주 받을 수 있기 때문이다.
  3. 테스트는 프로그래머를 위한 묘석인데, 두려움을 지루함으로 바꿔주는 효과가 있다.
  4. 버그가 있는 것 같다는 느낌을 실패하는 테스트로 치환하는 것도 한 사례가 될 수 있다. 이는 회귀 테스트와도 닮아있다.
  5. 실패할 것이 뻔하더라도 테스트를 작성한 뒤에는 꼭 실행해봐야한다.
  6. 테스트는 각각 완전히 독립적이어야한다. 서로 어떠한 영향도 주어서는 안된다.
  7. 테스트를 격리하기 위한 작업은 결과적으로 시스템이 응집도는 높고 결합도는 낮은 객체의 모음으로 구성되도록 한다.
  8. 경험이 축적될수록 할일 목록이 많아진다. 할일 목록이 많아질수록 내가 하던 일에 대한 집중력이 떨어지고 성취도도 낮아진다. 그러면 할일 목록은 더 많아진다. 할일 목록을 적어놓고 한번에 하나만 집중해야한다.
  9. 테스트를 먼저하면 스트레스가 줄고, 따라서 테스트를 더 많이 하게 된다.
  10. 시스템 개발 -> 완료된 시스템에 대한 이야기부터, 기능 개발 -> 기능이 완료되면 통과할 테스트부터, 테스트 작성 -> 완료될 때 통과할 단언부터
  11. 구현에 대해 전혀 고려하지 않고 테스트만 작성할 때도 사실 여러분은 몇 가지 문제들을 한번에 해결하는 것이다. (메서드 위치, 이름, 인터페이스 등)
  12. 테스트 작성에도 청중이 존재한다. 데이터 간에 차이가 있다면 그 속에 어떤 의미가 있어야 한다.
  13. 여러 의미를 갖는 동일한 상수를 쓰지 마라
  14. 테스트 자체에 예상되는 값과 실제 값을 포함하고 이 둘 사이의 관계를 드러내기 위해 노력하라
  15. 다음으로 작성할 테스트를 고를 때는, 뭔가를 가르쳐 줄 수 있으며, 구현할 수 있다는 확신이 드는 테스트를 골라라
  16. 우리는 아는 것에서 모르는 것으로 성장하는 프로그램을 갖게 된다.
  17. 첫 걸음으로 현실적인 테스트를 하나 작성한다면 상당히 많은 문제를 한번에 해결해야 하는 상황이 될 것이다. 이러면 어렵기도 하고 너무 오랫동안 피드백을 받을 수 없게된다.
  18. 사람들에게 그렇게 하라고 다짜고짜 밀어붙이는 것만큼 TDD가 퍼지는 것을 빨리 막는 건 없다. 테스트를 이용하여 묻고, 테스트를 이용하여 설명하는 것으로 시작해야한다.
  19. 테스트 작성은 뭔가를 배우기 위한 용도로 쓰일 수도 있다. (언어의 기능, 새로운 라이브러리, 새로운 스타일의 코드)

Affirmation (자기 선언)

  1. 나는 언제나 새로운 것을 스스로 찾아서 시도하고 배우는 사람이다.