Topic 41 테스트로 코딩하기
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
테스트는 버그를 찾기 위한 것이 아니다.
p.307
TDD 로 개발할 경우 단순히 버그를 찾는 것 이외에도 몸소 느낄 수 있는 장점이 많다.
테스트 케이스를 작성하기 위해서 우선 데이터들의 이상 값, 정상 값을 생각하고 에러가 발생했을 경우 등을 생각하게 됨으로 여러 상황에 해당하는 부분을 떠올리고 코드를 작성할 수 있다. 또한 자연스레 함수를 만들어 호출하다보니 의존성이 떨어지고 각 함수별로 기능이 명확하게 분리될 수 있다. 무엇이든 트레이드-오프가 있듯 너무 과도하게 테스트 케이스에 집착할 경우 기능 변경 시 테스트 케이스 수정이 너무 많고 나중에 관리가 되지 않아 의미없는 테스트가 될 가능성이 있다. 또한 너무 많은 시간을 사용해 효율적인 프로그래밍에 방해가 될 수 있다.
테스트가 코딩을 주도한다
우리 메서드의 테스트 작성에 대해 생각함으로써 코드의 작성자가 아니라 사용자인 것처럼 메서드를 외부의 시선으로 보게 되었다.
p.309
결국 함수 또한 API 이기 때문에 외부의 시선으로 볼 수 있다는 것은 매우 큰 장점이다. 필요한 값(인자)과 반환 값만 궁금하기 때문이다.
테스트가 코드의 첫 번쨰 사용자다.
p.309
너무 멋있는 말이라 넣어보았다. 테스트를 작성하면 생각해보다 빈번하게 테스트 케이스를 통과 못하는 것을 경험하는데 테스트가 첫 번째 사용자라고하니 더욱 이해가 된다.
무언가를 테스트하기 좋게 만들면 결합도도 낮아진다.
p.310
테스트하기 좋다는 것은 책임이 명확하고 독립적이라는 것을 의미하기에 당연히 결합도가 낮아진다.
코딩을 시작하기 전에 경계 조건의 테스트와 경계 조건에서 어떻게 동작해야 하는지를 먼저 생각해 본다면, 아마 함수를 단순하게 만드는 코드 패턴을 찾을 수 있을 것이다.
p.310
처리할 부분이 한 두개가 아니라면 머릿속은 얽히기 마련이다. 이럴 때 테스트 케이스 작성을 위해 데이터 값과 결과값을 그려볼 수 있다면 정리와 더불어 명쾌히 코드를 연상할 수 있다.
TDD: 목표가 어디인지 알아야 한다
상향식이나 하향식이 아니라 끝에서 끝까지(end-to-end) 만들어라.
p.313
저자는 상향식, 하향식을 따지지 말고 한쪽 끝과 다른 한쪽 끝을 잇는 조그만 기능 조각으로 만들라고 말한다. 이는 소프트웨어를 만드는 유일한 방법인 점진적인 방법이라고 소개하고 있다. 이해는 되지만 아직 와닿지는 않는다. 몇년 뒤에 보면 마음으로 이해할 수 있지 않을까 싶다.
다시 코드로
소프트웨어를 만들 때 맨 처음부터 테스트가 가능하도록 만들고, 코드들을 서로 연결하기 전에 코드를 하나하나 철저하게 테스트해야만 한다.
p.314
유닛 테스트로 작은 단위를 테스트하고 이를 묶는 통합 테스트를 진행해야한다. 그래야 추후 테스트 케이스가 실패하고 코드를 수정할 때 빠르게 원인을 파악할 수 있기 때문이다. 작은 단위가 불안정한데 큰 단위가 안정적일수는 없다. 그렇기에 큰 그림도 좋지만 작은 부분 하나하나를 만들어가야한다.
임시 테스트
디버깅 작업이 끝나면 이런 임시 테스트를 정식 테스트의 형태로 만들어 두어야 한다. 한 번 잘못된 코드라면 다시 잘못될 가능성이 높다. 여러분이 만든 테스트를 그냥 버리지 말고 기존의 단위 테스트 군단에 합류시켜라.
p.318
실행 중 동작이 되지 않거나 확인하고 싶은 값은 log 로 출력시키거나 디버깅을 한다. 저자는 이를 그냥 넘어가지말고 테스트로 만들기를 권장한다. 다시금 생각해보면 디버깅을 한다는 것은 중요한 부분을 확인한다는 것인데 테스트 케이스로 작성하기에 매우 적합하지 않나 싶다.
테스트 문화
여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.
p.320
마지막은 마음을 다잡는 말이다. 사용자가 테스트하게 되면 분명 좋은 피드백은 커녕 좋은 개발자가 아닐 것이다.
Topic 41 느낌
Topic 41 에서는 테스트에 대한 필요성과 장점, 정신을 소개하고 있다.