IT LAB

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.목에 대해 리팩터링 내성과 회귀 방지를 최대화해서 최대 가치의 통합 테스트 개발하기 1. 목의 가치를 극대화하기public class UserController { private readonly Database _database; private readonly EventDispatcher _eventDispatcher; UserController(Database database, IMessageBus messageBus, IDomainLogger domainLogger) { _database = database; _eventDispatcher = new EventDispatcher(mes..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 4. 의존성 추상화를 위한 인터페이스 사용인터페이스와 느슨한 결합인터페이스 목적의 잘못된 인식프로세스 외부 의존성을 추상화하여 느슨한 결합을 달성단일 구현일 경우, 추상화가 아니게 됨진정한 추상화는 발견하는 것이지 발명하는 것이 아님 (적어도 구현이 두가지 이상 있어야 함)YAGNI 위반기존 코드를 변경하지 않고 새로운 기능을 추가해 공개 폐쇄 원칙을 지킴 프로세스 외부 의존성에 인터페이스를 사용하는 이유는?목을 사용하기 위함인터페이스가 없으면 테스트 대역을 만들 수 없음즉, 비관리 의존성만 인터페이스를 두기 5. 통합 테스트 모범 사례도메인 모델 경계 명시하기도메인 클래스와 컨트롤러 사이의 명확한 경계로 단위 테스트와 통합 테스트의 차..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 단위테스트만으로 전체 시스템이 잘 동작하는지 확신할 수 없음비즈니스 로직을 격리된 상태로 확인하는 것만으로는 충분하지 않음각 부분이 외부 시스템과 어떻게 통합되는지 확인해야 함 1. 통합 테스트는 무엇인가?통합 테스트의 역할통합 테스트단위 테스트의 요구 사항을 하나라도 충족하지 못하는 테스트단일 동작 단위를 검증빠르게 수행다른 테스트와 별도로 처리컨트롤러를 대상으로 하는 테스트시스템이 외부 의존성과 통합해 어떻게 작동하는지를 검증함 다시보는 테스트 피라미드단위 테스트와 통합 테스트의 비율단위 테스트로 가능한 한 많이 비즈니스 시나리오의 예외 상황을 확인통합 테스트로 주요 흐름과 단위 테스트가 다루지 못하는 기타 예외 사항 다루기 통합 테..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 2. 가치 있는 단위 트스트를 위한 리팩터링하기고객 관리 시스템이메일 변경사용자 이메일이 회사 도메인에 속한 경우, 해당 사용자는 직원으로 표시됨 (그렇지 않으면 고객으로 간주)시스템은 회사의 직원 수를 추적해야 함이메일이 변경되면 시스템은 메시지 버스로 메시지를 보내 외부 시스템에 알려야 함 초기 구현 (복잡한 코드)public class User { public int UserId { get; private set; } public string Email { get; private set; } public UserType Type { get; private set; } public void Chan..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 리팩터링할 코드 식별하기코드 유형복잡도 또는 도메인 유의성복잡도코드 내 의사 결정 지점 수로 정의도메인 유의성코드가 프로젝트의 문제 도메인에 대해 얼마나 의미있는가특징단위 테스트에서 가장 이로움 (회귀방지 Good)서로 독립적 협력자 수가변 의존성외부 의존성도메인 모델에서 사용해서는 안됨 (목 체계가 복잡해지기 때문)애플리케이션 계층을 넘나드는 코드에만 작성하기 (리팩토링 내성 고려)특징협력자가 많은 코드는 테스트 비용이 많이 듬 (셋팅 코드) 험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기지나치게 복잡한 코드복잡도 및 도메인 유의성도 높고 협력자수도 많은 코드ex) 프레임워크 의존성에 결합(비동기, 멀티스레딩), UI, 외부..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 함수형 아키텍처 이해함수형 프로그래밍수학적 함수를 사용한 프로그래밍숨은 입출력이 없는 함수모든 입출력은 메서드 시그니처에 명시되어야 함호출 횟수에 상관없이 주어진 이력에 대해 동일한 출력을 생성함 참조 투명성int add(int a, int b) { return a + b; } // add(2, 3) == 5어떤 표현식이 항상 같은 값으로 표현될 수 있는 특징코드의 예측 가능성 및 불변성을 보장함 숨은 입출력 유형부작용메서드 시그니처에 표시되지 않은 출력 (숨어있음)ex) 디스크 파일 업데이트, 인스턴스 상태 변경예외메서드가 예외를 던지면, 계약을 우회하는 경로가 만들어짐호출 스택의 어느 곳에서도 발생할 수 있음내외부 상태에 대한 참..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 단위 테스트의 세 가지 스타일출력 기반 테스트테스트 대상 시스템에 입력을 넣고, 생성되는 출력을 점검하는 방식부작용이 없으므로 반환 값만 검증하면 됨 함수형 프로그래밍부작용 없는 코드 선호를 강조하는 프로그래밍 방식 상태 기반 테스트작업이 완료된 후 시스템 상태를 확인하는 것의존성의 상태를 의미할 수 있음 통신 기반 테스트목을 사용해 테스트 대상 시스템과 협력자 간의 통신을 검증 2. 단위 테스트 스타일 비교회귀 방지와 피드백 속도 지표로 스타일 비교하기회귀 방지지표테스트 코드 양코드 복잡도도메인 유의성특정 스타일에 따라 달라지지 않음 테스트 피드백 속도테스트 스타일과 테스트 피드백 속도 사이에는 상관관계가 거의없음 리팩터링 내성 지..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.3. 목과 테스트 취약성 간의 관계육각형 아키텍처도메인애플리케이션의 중심부.비즈니스 로직이 포함되어 있음. 애플리케이션 서비스도메인 계층 위에 있음외부 환경과의 통신을 조정함도메인 클래스와 프로세스 외부 의존성 간의 작업을 조정함 계층간의 관심사 분리전형적인 애플리케이션은 도메인과 애플리케이션 서비스라는 두 계층으로 구성됨책임을 변환하여 알맞게 책임질 수 있도록 하기 단방향 통신애플리케이션 서비스 계층에서 도메인 계층으로 흐르는 의존성 흐름을 규정함애플리케이션 서비스 계층은 도메인 계층에 대해 알고 있음도메인 계층은 외부 환경으로부터 완전히 격리됨 프렉탈전체와 부분이 동일한 패턴이나 구조를 가진다는 개념계층마다 동일한 테스트 목표를 유지 ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 목과 스텁 구분테스트 대상 시스템과 그 협력자 사이의 상호 작용을 검사할 수 있는 테스트 대역 목외부로 나가는 상호 작용을 모방하고 검사하는 용도SUT가 상태를 변경하기 위한 의존성을 호출하는 상황ex) 메일 호출 스텁내부로 들어오는 상호 작용을 모방하는 용도SUT가 입력 데이터를 얻기 위한 의존성을 호출하는 상황ex) 데이터베이스 조회 스텁으로 상호 작용을 검증하지 말라스텁은 내부로 들어오는 상호 작용만 모방하고 검사하지 않음SUT에서 스텁으로의 호출은 SUT가 생성하는 최종 결과가 아님최종 결과를 산출하기 위한 수단내부 구현 세부 사항에 해당됨이러한 호출을 검증하는 것은 테스트 취약성으로 이어질 수 있음 (과잉 명세) CQSCom..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.3. 이상적인 테스트를 찾아서테스트의 가치좋은 단위 테스트의 4대 특성을 곱하여 얻은 결과추정치이며, 테스트 스위트에 테스트를 계속 둘지 여부를 결정할 수 있음임계치를 충족하는 테스트만 두어, 책임을 적절하게 맡도록 해야 함소수의 가치있는 테스트가 평범한 테스트보다 프로젝트 성장에 훨씬 더 효과적 이상적인 테스트를 만들 수 있는가?이상적인 테스트는 네 가지 특성 모두에서 최대 점수를 받는 테스트 모두 만점의 점수를 얻는 테스트는 불가능함회귀 방지, 리팩터링 내성, 빠른 피드백은 상호 배타적이기 때문셋중 하나를 희생해야 나머지 둘을 최대로 할 수 있음 다른 특성에 집중하려고 하나의 특성을 버릴 수 없음곱셈 규칙으로 인해 가치가 0으로 가까워..