내 머리에 담을 만한 코드 덩어리
다루고 있는 코드의 덩치가 커지면 문제의 원인을 찾는게 어려워 진다. 덩어리 코드는 내 머리 속에 잘 담기지 않는다. 머리 속에 담지 못했으니 무엇 부터 손대야 될지 모르겠는 막막한 상태에 놓이곤 한다. 결국 내 머리 속에 담을 만한 단위로 나누어 내지 못하면 운에 기대어 여기 저기 들 쑤시며 원인을 찾곤 한다. 다루고 있는 코드를 내 머리에 담을 만한 크기로 나누어 내자. 그래야 내가 더 차근차근 만족을 먹으며 일할 수 있다.
네거티브 테스트
TDD를 하면 실패하는 것을 먼저 학인하고 성공하게 만들기 때문에 더 안심이 된다는 일기를 쓴적이 있다. 오늘은 기능 코드를 먼저 작성하고 테스트 코드를 작성했다. 테스트 코드가 제대로 작성되었는지 확신할 수 없는데 테스트에 초록불이 들어온다. 테스트 성공이 진짜 성공인지 확인하기 위해 실패하게 변수를 조정해 보았다. 이런! 테스트가 여전히 성공이다. 테스트 코드가 잘못 작성된 것이다. 한참을 실패하는 값을 조정해 보고 테스트 코드를 고친 후 테스트 코드가 실패와 정상을 구분해 낸다. 네거티브 테스트를 먼저 작성하라는 토비의 스프링 책 조언이 뼈저리게 생각난다.
강하게 결합된 메서드
미션을 준비하는 init() 메서드와 미션을 시작하는 start() 메서드를 테스트하기 시작했다. init()에서 준비한 데이터를 start()에서 사용하는 구조로 되어 있었는데 init()에서 수행된 어떤 동작들 때문에 start() 동작 결과를 독립적으로 확인하는데 어려움이 있다. 그래서 init()과 start()에서 사용하는 데이터를 독립적으로 만들었다. 테스트도 완전히 나누었다. 불필요하게 강하게 결합되어 있던 두 메서드를 독립적으로 만든 것이다. 테스트는 역시 코드 사용자가 되어 코드 개선을 이루는데 많은 도움이 되는 것 같다.
