인상 깊은 단락 p30 대부분의 프로그래머는 단위 테스트를 실천하고 중요성을 알고 있다. 단위테스트를 적용해야하지는 더 이상 논쟁거리가 아니다.
논쟁은 ‘단위 테스트를 작성해야 하는가?‘에서 ‘좋은 단위 테스트를 작성하는 것은 어떤 의미인가?‘로 바뀌었다.
p32 테스트하기 쉬운 코드는 좋은 코드의 필요조건이지만 충분 조건은 아니다.
코드를 단위 테스트하기 어렵다면 코드 개선이 반드시 필요하다는 것을 의미한다.
코드베이스를 쉽게 단위 테스트할 수 있다고 해도 반드시 코드 품질이 좋은 것을 의미하지는 않는다.
인상적인 단락 p5 단위테스트를 ‘다른 단위에 종속되지 않는 하나의 단위에 대한 테스트’
p71 개발자 입장에서 무언가를 잘못 수정할 때마다 바로바로 알려주는 누군가가 곁에 있어주는 것만큼 마음 든든한 일도 없다. 단위 테스트는 잘못된 부분을 찾기 위해 어플리케이션을 디버깅할 필요성을 줄여준다. 기능 테스트가 버그가 존재하는 유즈케이스를 골라주는 수준이라면, 단위 테스트는 어떤 메서드가 어떤 이유로 실패했는지도 이야기해준다. 즉 문제를 찾아 몇시간씩 헤매던 일에서 해방된다.
p99 숨겨진 종속성과 전역상태를 피하라 싱글톤은 애플리케이션에 전역 상태를 만들어낸다는 명백한 취약점이 존재한다.
생각 메모 체계적으로 잘 정리되어 있으나, 책 두께에 비하면 핵심은 많지는 않음 많은 용어가 경험있는 사람에게는 섬세한 구분으로 와 닿을듯하나, 그렇지 않은 사람에게는 부담이 될 수도 있을듯 관련 링크 http://xunitpatterns.com/ https://martinfowler.com/bliki/TestDouble.html 정리 Fixture : SUT(System under test)를 실행하기 위해 필요한 모든 것 픽스처를 설치하기 위해 호출하는 테스트 로직부분 setup : 테스트 대상 시스템(SUT)에서 원하는 로직을 실행시키기 위해 설치해야 하는 테스트 선조건, 모든 객체와 객체의 상태 뒷문설치 공유 픽스처 신선한 픽스쳐(Fresh Fixture).
감상 2010.06.20 만일 당신이 때때로 실패하지 않는다면, 그건 안이하게 살고 있다는 확실한 증거다. -우디앨런
JUnit, Mock 라이브러리 등에 대한 최신 설명이 잘 정리되어 있다. 내년도 신입사원 교육도 내가 하게 된다면, 이 책을 참고도서로 강추할 예정.
인상 깊은 단락 p98 JUnit 탄생 일화
p249 Mock 프레임워크 트렌드
p321 실패라는 건 없다. 모든 건 피브백일 뿐이다. - 로버트 알렌
p446 SI에서 TDD
인상깊은 부분 많은 C개발자들이 플랫폼마다 달라지는 코드를 처리할때 조건부 컴파일을 이용한다. 나는 여러분에게 조건부 컴파일을 피하라고 제안한다. 코드를 지저분하게 만들기 때문이다. 또한 특정 상황에서 어떤 코드가 실제로 컴파일 되는지 알아보기도 힘들다.
(중략) 플랫폼마다 따로 구현될 함수들의 프로토타입을 정의하는 헤더 파일을 만들었다. 그런 다음 각 플랫폼 구현을 해당 디렉터리에 넣어서 분리시켰다. 우리는 전처리기 대신에 컴파일러와 링커를 사용했다.’
추천사 … 이 책 ‘임베디드 C를 위한 TDD'는 기존의'코딩 많이 하고 디버깅 시작하기’ 식의 개발 방법과 TDD가 어떻게 다른지 본질적인 차리를 잘 보여준다.
인상 깊은 부분 25쪽 TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. “일주일간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가” 물론, TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고, 또 의식적으로 제어했기 때문이다.
26쪽 동시성 테스트와 CSP
145쪽 TDD로 구현할 땐 테스트 코드이 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다.