IT LAB

[단위 테스트] 6-1. 단위 테스트 스타일: 단위 테스트 스타일

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

[단위 테스트] 5-2. 목과 테스트 취약성: 통신

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

[단위 테스트] 5-1. 목과 테스트 취약성: 목

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

[단위 테스트] 4-2. 좋은 단위 테스트의 4대 요소: 이상적인 테스트

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

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 좋은 단위 테스트의 4대 요소 자세히 살펴보기회귀 방지회귀소프트웨어 버그코드를 수정한 후, 기능이 의도한 대로 작동하지 않는 경우를 의미함코드는 책임이며, 작성할수록 더욱 많은 버그에 노출됨프로그램이 커질수록 코드가 늘어나므로 회귀를 방지하는 것이 중요 테스트 점수테스트 코드 양코드 복잡도코드의 도메인 유의성 리팩터링 내성애플리케이션 코드를 리팩토링하더라도 관련 테스트가 제대로 동작하는지를 의미함 거짓 양성허위 경보실제로 기능은 잘 동작하지만, 테스트는 실패라 하는 경우영향코드 문제에 대응하는 능력이 떨어지고 희석됨리팩토링이 줄어즘원인일반적으로 코드를 리팩토링할 때 발생함테스트 대상 시스템이 구현 세부 사항이 많이 결합할수록 더 많이..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. AAA 패턴테스트를 준비, 실행, 검증 세 부분으로 나누어 구성하는 방법 구조준비: SUT와 의존성 셋팅실행: SUT에서 메서드 호출 및 의존성 전달검증: 결과 검증. (반환 값이나 SUT나 협력자의 상태, SUT가 호출한 메서드 등) 장점일관성: 스위트 내 모든 테스트가 단순하고 균일한 구조를 갖는 데 도움이 됨 2. 권장 사항여러 개의 준비, 실행, 검증 구절 피하기여러 개의 실행 구절은 여러 개의 동작 단위를 검증하는 테스트임을 의미함이러한 구조는 단위 테스트가 아닌 통합 테스트임을 의미함 테스트 내 if 문 피하기한번에 너무 많은 것을 검증한다는 표시분기가 있어서 얻는 이점이 없음테스트를 읽고 이해하는 것을 더 어렵게 함반드시..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 2. 런던파와 고전파격리 특성에 따라 나뉨 런던파작은 코드 조각 단위테스트 대상 시스템을 협력자에게서 완전히 격리모든 의존성을 Mock으로 대체코드 조각을 테스트 대역으로 분리 (단, 불변 비공개 의존성은 제외) 하향식 TDD전체 설계와 인프라부터 준비하고, 이를 기반으로 상위 레벨 테스트 및 하위 레벨 구현 장점입자성테스트 실패 시, 코드베이스의 어느 부분이 고장 났는지 명확히 알 수 있음의존성에서 문제가 발생하면 테스트가 실패함SUT의 문제인지 직관적으로 확인할 수 없음객체 그래프를 분할할 수 있음객체 그래프를 재생성하지 않아도 됨서로 연결된 클래스의 그래프가 커져도 테스트 용이 단점과잉 명세과도한 명세로 인해 테스트가 SUT의 세부..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. '단위 테스트'의 정의단위 테스트란작은 코드 조각 단위로빠르고 자동으로 실행격리된 방식 격리단위 테스트는 격리된 환경에서 실행되야 함테스트는 순서에 의존하지 않아야 하며, 독립적으로 실행 가능한 상태여야 함 공유 의존성테스트 간에 공유되고 서로의 결과에 영향을 미칠 수 있는 상태나 데이터상태변경이 허용될 경우, 테스트 간 영향을 끼칠 수 있음공유 의존성을 제거하거나, 모의 객체로 대체정적 가변 필드 등 비공개 의존성애플리케이션의 실행 흐름에서 보이지 않는 의존성메모리 기반의 프록시로 대체데이터베이스 연결, 시스템 접근 등 프로세스 의존성애플리케이션 실행 프로세스 외부에서 실행되는 의존성의존성을 대체할 Mock 시스템 사용메시지 큐, ..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.1. 테스트 스위트 품질 측정을 위한 커버리지 지표커버리지 지표테스트 스위트가 소스 코드를 얼마나 실행하는 지를 백분율로 나타내는 지표테스트 스위트의 품질을 평가하는데 자주 사용됨 문제점public String categorizeAge(int age) { if (age 테스트 대상 시스템의 모든 가능한 결과를 검증한다 보장할 수 없음 @Testpublic void testIsValidInput() { assertTrue(isValidInput("abcdef")); // 단일 입력값만 테스트}private boolean isValidInput(String input) { return StringUtils.isNotEmpty..

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 1. 단위 테스트 현황비율제품 코드와 테스트 코드의 비율은 1:1~3 정도 새로운 기능과 버그 발생새로운 기능을 구현할 때 새로운 버그가 지속적으로 나타남 테스트 코드 작성의 어려움적절하지 않은 설계의 코드를 테스트할 경우, 테스트 코드를 작성하는데 어려움이 있음잘못된 테스트 코드는 오히려 상황을 더 악화시킬 수 있음 2. 단위 테스트 목표소프트웨어 엔트로피프로젝트에서는 시간이 지날수록 코드베이스의 복잡성과 불확실성이 증가하는 경향이 있음 엔트로피 증가코드 변경시 엔트로피는 증가함기존 기능에 영향을 주어 예기치 못한 문제가 발생테스트가 없는 프로젝트는 시작은 유리하지만 이내 진척이 없을 정도로 느려짐결국 코드베이스를 신뢰할 수 없음 목표..