‘단위 테스트’의 정의 단위 테스트는 작은 코드 조각을 검증하고, 빠르게 수행하고, 격리된 방식으로 처리하는 자동화된 테스트다. 격리 문제는 단위 테스트의 고전파와 런던파를 구분할 수 있게 해주는 근원적 차이에 속한다. 격리 문제에 대한 런던파의 접근 런던파에서는 테스트 대상 시스템을 협력자에게서 격리한다. 하나의 클래스가 다른 클래스 또는 여러 클래스에 의존하면 이 모든 의존성을 테스트 대역(test double)으로 대체해야 한다. 장점 테스트가 실패하면 코드베이스의 어느 부분이 고장 났는지 확실히 알 수 있다. 객체 그래프를 분할할 수 있다....
단위 테스트를 구성하는 방법 AAA 패턴 사용 AAA 패턴은 각 테스트를 준비(arrange), 실행(act), 검증(assert)이라는 세 부분으로 나눌 수 있다. 준비 구절: 테스트 대상 시스템(SUT)과 해당 의존성을 원하는 상태로 만든다. 실행 구절: SUT에서 메서드를 호출하고 준비된 의존성을 전달하며 출력 값을 캡처한다. 검증: 결과를 검증한다. SUT의 반환 값이나, SUT 협력자의 최종 상태, SUT가 협력자에 호출한 메서드 등으로 결과를 검증할 수 있다. Given-When-Then 패턴과 차이점은 없다. 유일한 차이점은 프로그래머가 아닌 사람에게 Given-When-Then 구조가 더 읽기 쉽다는 것이다....
단위 테스트 현황 기업용 애플리케이션 개발 프로젝트는 제품 코드와 테스트 코드 비율을 1:1에서 1:3 정도 된다. 테스트 작성에 그치지 않고 노력 대비 최대의 이익을 이끌어내는 방식으로 단위 테스트를 작성하는 것이 중요하다. 단위 테스트의 목표 코드 조각을 단위 테스트할 수 없으면 설계 품질이 낮은 것이지만, 코드 조각을 단위 테스트할 수 있다고 설계 품질이 좋은 것은 아니다. 단위 테스트 목표는 소프트웨어 프로젝트의 지속 가능한 성장을 가능하게 하는 것이다. 테스트를 작성하지 않으면 코드 베이스에서 무언가를 변경할 때마다 소프트웨어 엔트로피가 증가한다....
목의 가치 극대화하기 비관리 의존성에만 목을 사용하게끔 제한하는 것은 중요하지만, 이는 목의 가치를 극대화 하기 위한 첫 번째 단계일 뿐이다. 시스템 끝에서 상호 작용 검증하기 시스템 끝에 있는 비관리 의존성을 목킹하여 상호 작용을 검증하라. 어떤 라이브러리에 대한 래퍼 클래스가 있으면, 래퍼 클래스 내에 있는 라이브러리 클래스를 목으로 검증하라. 시스템의 끝에서 상호 작용을 확인하면 회귀 방지가 좋아질 뿐만 아니라 리팩터링 내성도 향상된다. 목을 스파이로 대체하기 스파이는 수동으로 작성하는 반면에 목은 목 프레임워크의 도움을 받아 생성한다는 것이 차이점이다....
단위 테스트에만 전적으로 의존하면 시스템이 전체적으로 잘 작동하는지 확신할 수 없다. 통합 테스트는 무엇인가? 통합 테스트의 역할 아래 단위 테스트 세 가지 요구 사항중 하나라도 충족하지 못하면 통합 테스트의 범주에 속한다. 단일 동작 단위를 검증하고, 빠르게 수행하고, 다른 테스트와 별도로 처리한다. 단위 테스트는 도메인 모델을 다루는 반면, 통합 테스트는 프로세스 외부 의존성과 도메인 모델을 연결하는 코드(컨트롤러)를 확인한다. 다시 보는 테스트 피라미드 통합 테스트는 유지비가 많이 든다. 프로세스 외부 의존성 운영이 필요함 관련된 협력자가 많아서 테스트가 비대해짐 단위 테스트로 가능한 한 많이 비즈니스 시나리오의 예외 상황을 확인하고, 통합 테스트는 주요 흐름(happy path)과 단위 테스트가 다루지 못하는 기타 예외 상황을 다룬다....
리팩터링할 코드 식별하기 코드의 네 가지 유형 모든 프로덕션 코드는 2차원으로 분류할 수 있다. 복잡도 또는 도메인 유의성 복잡도: 코드 내 의사 결정 지점 수로 정의한다. 도메인 유의성: 코드가 프로젝트의 문제 도메인에 대해 얼마나 의미 있는지를 나타낸다. 복잡한 콤드와 도메인 유의성을 갖는 코드가 단위 테스트에서 가장 이롭다. 협력자 수: 가변 의존성이거나 프로젝트 외부 의존성이다. 도메인 모델이라면 프로세스 외부 협력자를 사용하면 안 된다. 테스트에서 목 체계가 복잡하기 때문에 유지비가 더 든다. 네 가지 코드 유형 도메인 모델과 알고리즘 도메인 모델 또는 복잡한 알고리즘 단위 테스트 하면 가장 이롭다....
단위 테스트의 세 가지 스타일 단위 테스트의 세 가지 스타일 출력 기반 테스트 상태 기반 테스트 통신 기반 테스트 테스트 품질: 출력 기반 > 상태 기반 > 통신 기반 출력 기반 테스트 정의 SUT에 입력을 넣고 생성되는 출력을 점검하는 방식 출력 기반 테스트 스타일은 사이드 이펙트가 없는 순수 함수 방식으로 작성된 코드에만 적용된다. 상태 기반 스타일 정의 작업이 완료된 후 시스템 상태를 확인 상태는 SUT나 협력자 중 하나, 또는 데이터베이스나 파일 시스템 등과 같은 프로세스 외부 의존성의 상태 등을 의미할 수 있다....
목과 스텁 구분 테스트 대역 유형 목: 외부로 나가는 상호 작용을 _모방_하고 _검사_한다. 이러한 상호 작용은 SUT가 상태를 변경하기 위한(사이드 이펙트가 있는) 의존성을 호출하는 것에 해당한다. 목과 스파이로 분류할 수 있다. 스파이는 수동으로 작성하는 반면, 목은 목 프레임워크의 도움을 받아 생성한다. 스텁: 내부로 들어오는 상호 작용을 _모방_한다. 이러한 상호 작용은 SUT가 입력 데이터를 얻기 위한 의존성을 호출하는 것에 해당한다. 스텁, 더미, 페이크로 분류할 수 있다. 더미: 널값이나 가짜 문자열과 같이 단순하고 하드코딩된 값이다....
좋은 단위 테스트 스위트의 특성 개발 주기에 통합돼 있다. 코드베이스의 가장 중요한 부분만을 대상으로 한다. 최소한의 유지비로 최대 가치를 끌어낸다. 가치있는 테스트를 작성하려면 가치있는 테스트를 식별할 수 있어야 한다. 좋은 단위 테스트의 4대 요소 자세히 살펴보기 좋은 단위 테스트 네 가지 특성 회귀 방지 리팩터링 내성 빠른 피드백 유지 보수성 첫 번째 요소: 회귀 방지 회귀: 코드를 수정한 후 기능이 의도한 대로 작동하지 않는 경우 회귀 방지 지표에 대한 테스트 점수가 얼마나 잘 나오는지 평가하려면 다음 사항을 고려해야 한다....
안티 패턴: 겉으로 적절한 것처럼 보이지만 장래에 더 큰 문제로 이어지는 반복적인 문제 비공개 메서드 단위 테스트 비공개 메서드와 테스트 취약성 비공개 메서드를 노출하는 경우 식별할 수 있는 동작만 테스트하는 것을 위반한다. 비공개 메서드를 노출하면 테스트가 구현 세부 사항과 결합되고 결과적으로 리팩터링 내성이 떨어진다. 비공개 메서드와 불필요한 커버리지 비공개 메서드가 너무 복잡해서 식별할 수 있는 동작으로 테스트하기에 충분히 커버리지를 얻을 수 없는 경우가 있다. 이런 경우 두 가지 문제가 존재할 수 있다....
애플리케이션 데이터베이스: 다른 애플리케이션이 접근할 수 없는 데이터베이스 데이터베이스 테스트를 위한 전제 조건 테스트를 작성하기 전에 통합 테스트가 가능하게끔 준비 단계를 수행해야 된다. 형상 관리 시스템에 데이터베이스 유지 모든 개발자를 위한 별도의 데이터베이스 인스턴스 사용 데이트베이스 배포에 마이그레이션 기반 방식 적용 데이터베이스를 형상 관리 시스템에 유지 데이터베이스를 테스트하는 방법의 첫 번째 단계는 데이터베이스 스키마를 일반 코드로 취급하는 것이다. 일반 코드와 마찬가지로 데이터베이스 스키마는 Git과 같은 형상 관리 시스템에 저장하는 것이 최선이다....