인상 깊은 단락 p30 대부분의 프로그래머는 단위 테스트를 실천하고 중요성을 알고 있다. 단위테스트를 적용해야하지는 더 이상 논쟁거리가 아니다.
논쟁은 ‘단위 테스트를 작성해야 하는가?‘에서 ‘좋은 단위 테스트를 작성하는 것은 어떤 의미인가?‘로 바뀌었다.
p32 테스트하기 쉬운 코드는 좋은 코드의 필요조건이지만 충분 조건은 아니다.
코드를 단위 테스트하기 어렵다면 코드 개선이 반드시 필요하다는 것을 의미한다.
코드베이스를 쉽게 단위 테스트할 수 있다고 해도 반드시 코드 품질이 좋은 것을 의미하지는 않는다.
http://www.yes24.com/Product/Goods/2495264?OzSrank=1
인상 깊은 단락 p22 최근까지도 국내에서 수행되는 대부분의 성능 시험 프로젝트의 경우 성능 시험 도구 라이센스에 대한 비용 부담 및 Think 시간 측정의 어려움, 성능 시험 소요 시간의 단축, 관련자들의 이해 부족 등의 이유로 Think 시간을 배제하거나 대폭 줄인 채로 성능 시험을 실시하고 있는 상황입니다. 이는 시험 목표와는 전혀 다른 결과를 도출할 수 있는 비현실적인 상황을 재현하는 것으로 이를 통해 성능을 개선하는 것은 의미가 없다고 단언할 수 있습니다.
인상 깊은 단락 Introduction Agile acceptance testing breaks down traditional boundaries around testing, requirements and specification processes in a way that significantly improves communication on a project.
It is intentionally not too technical or suited only for programmers, because agile acceptance testing is not a programming technique: it is a communication technique that brings people involved in a software project closer.
One of the main messages I want to convey with this book is that the biggest benefit of agile acceptance testing is improved communication and mutual understanding, not test automation.
( 이미지 출처 Yes24 : http://www.yes24.com/24/Goods/3937865?Acode=101 )
감상 선배로부터 들었던 주옥같은 조언들, 평소 막연히 생각은 했지만 체계화하지 못했던 원칙들이 잘 정리되어 있다. 특정 개발환경에만 국한되지 않는 보편적인 원칙들로 채워져 있어서, 시간이 지나도 이 책의 가치는 바래지지 않을듯..
인상 깊은 부분 p65 동시에 여러 개를 변경하면 잘못된 결론에 이를 수 있다.
p68 뭐든지 우리가 이해하지 못하는 부분은 잠재적인 버그다.
p76 디버깅은 순간이지만 테스트는 남는다.
디버거가 디버깅 방법 중에서 가장 강력한 것임에는 틀림없다.
감상 입문자에게 눈높이를 맞춰서 맛뵈기로 다양한 도구를 잘 소개했다. 해킹을 예방하는 규칙은 단순하다. 네트워크와 포트는 최소한도로 개방하고, 어플리케이션에 과도한 권한 안주고, 비밀번호 단순하게 하지 않고, 각종 패치 적용 잘하고.. 몰라서 못 지키는것은 아닌데, 설마하는 마음에 지나치기 쉽다. 이 책을 보면 해커들이 얼마나 편하게 쓸 수 있는 도구가 많은지를 알게 되어서 조금은 더 부지런하게 보안에 대비하게 될 것 같다.. 핵심 요약 1. 침투 테스트 소개 백트랙 리눅스 침투 테스트를 위한 종합 백화점
인상적인 단락 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가 어떻게 다른지 본질적인 차리를 잘 보여준다.
지속적인 통합: 소프트웨어 품질을 높이고 위험을 줄이기
인상 깊은 단락 47쪽 품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻한다.
137쪽 테스트 분류
단위테스트 컴포넌트 테스트 시스템 테스트: JWebUnit 처럼 기능테스트(=인수테스트) : 실제 브라우저 사용 JWebUnit 예제
156쪽 테스트 케이스 하나에 ASSERT 하나로 제한하기
167쪽 수년간 이 메트릭에 대해 다양한 연구를 했는데, 10보다 큰 CCN을 가진 메서드는 같은 코드의 다른 코드보다 결함이 발생할 위험이 크다는 게 밝혀졌습니다.
인상 깊은 부분 25쪽 TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. “일주일간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가” 물론, TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고, 또 의식적으로 제어했기 때문이다.
26쪽 동시성 테스트와 CSP
145쪽 TDD로 구현할 땐 테스트 코드이 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다.