정글에서 온 개발자

통합테스트 이유단위 테스트에만 전적으로 의존하면 시스템이 전체적으로 잘 작동하는지 확신할 수 없다.단위 테스트가 아닌 테스트는 모두 통합테스트다.단위 테스트는 도메인 모델을 다루고, 통합테스트는 프로세스 외부 의존성과 도메인 모델을 연결하는 코드를 확인한다.어플리케이션이 간단할수록(도메인 로직이 없을 수록) 통합테스트 수와 단위테스트 수가 같아진다. (단위테스트가 오히려 없을 수도 있다.)주의사항통합테스트는 주요흐름(happy path)와 단위테스트가 못 다루는 예외상황(edge case)를 다룬다.외부 의존성과의 상호작용을 모두 확인하도록 작성하고, 부족하면 모두 확인하게 추가 작성한다.빠른 실패 (코드에서의 예외 던지기) 를 하면 테스트가 필요없다. 이를 통해 통합테스트의 추가 작성 비용을 줄일 수 ..

오늘의 팁추상화할 것(구현체)을 테스트하기보다 추상화를 테스트하는 것이 더 쉽다.도메인 이벤트는 프로세싀 외부 의존성 호출 위의 추상화도메인 클래스의 변경은 데이터 저장소의 향후수정에 대한 추상화컨트롤러에 비즈니스 로직이 있는 것을 완전히 피할 수 없다.도메인 클래스에서 모든 협력자를 완전헤 제거할 수 있는 경우도 거의 없다.    그러나 최소한 외부 프로세스는 참조하지 않게 하자.    그리고 남은 협력자들과의 호출은 구현 세부 사항이다 -> 상호작용을 검증하지 말자어떤 협력자와 어떻게 소통해서 결과를 내는지는 검증하지 말자.그러나 해당 협력자의 소통 메서드는 검증할 수 있다. (더 아래 레이어로 내려가서)세부사항인지, 식별가능인지의 구현은 클라이언트가 누구냐에 달려있다.양파껍질처럼 계층을 바꾸면서 클..

테스트의 효과단순한 검증이라기보다는 설계의 문제다.프로그래머가 수정 중 중요한 것을 망가뜨릴 염려를 없앨 수 있다.프로그래머가 다른 관점에서 문제를 해결할 수 있다. - 호출자 관점에서 보게 된다. -> 편리하게 호출할 수 있는 소프트웨어를 설계하게 된다.반드시 테스트 가능한 프로그램을 설계하도록 강제할 수 있다. -> 소프트웨어를 다른 환경과 분리하도록 강제한다.테스트 자체가 문서화다.인수테스트인수 테스트는 기능 요소의 궁극적인 문서화 형태다.인수테스트 고려가 시스템의 아키텍처에 큰 영향을 준다. -> 인수테스트를 스크립트나 XML로 하기 위해 자연스럽게 트랜잭션 소스, 출력 매커니즘 등을 분리하게 된다.리팩토링모듈을 읽기 쉽고 변경하기 쉽게 만들기 위해 필요한 것은 원칙과 패턴에 더해 주의력과 훈련이..