kdh93

CGLIB: 바이트 코드를 조작해 동적으로 클래스를 생성해주는 라이브러리 인터페이스 없이 구체 클래스만 존재해도 프록시를 만들어 낼 수 있다. 외부 라이브러리지만, Spring FrameWork 내부 소스코드에 포함되어있음, 별도 추가 X MethodInteceptor 를 제공한다. package org.springframework.cglib.proxy; public interface MethodInterceptor extends Callback { Object intercept( Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable; } obj : CGLIB이 적용된 객체 method: 호출된 메서드 args: 메서드..

"rm "

테스트는 왜 필요할까? 문서화 품질 보증 내가 작성한 코드의 의도를 확실하게 이해했는가? 자동화 검증 Mock 테스트를 위한 대역 가짜 행위를 정의하는것 : Stubbing BDDMockito Clasicist VS Mockist 테스트 환경의 독립성. 테스트간의 의존성을 가지게하지 말자. 공유 변수 금지

Test Driven Development 프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현과정을 주도하도록 하는 방법론 RED : 실패하는 테스트를 먼저 작성. GREEN : 테스트 통과하는 최소한의 프로덕션 코드 작성. REFACTOR : 구현 코드 개선, 테스트 통과 유지 TDD 의 장점 피드백이 빠름 복잡도 낮은, 테스트 가능한 코드로 구현 가능하다. 쉽게 발견하기 어려운 엣지 케이스를 놓치지 않을 수 있다. 과감한 리팩토링이 가능해짐. 테스트가 통과하도록 계속 검증 가능. 선 기능 구현 후 테스트 작성의 단점 테스트 자체의 누락 가능성 특정 테스트 케이스만 검증할 가능성 (해피케이스) 잘못된 구현을 다소 늦게 발견할 가능성. 클라이언트(테스트) 관점에서 피드백을 줄 수 있다.

테스트 케이스 = 문서 문서적인 측면 프로덕션 기능을 설명하는 테스트 코드 다양한 케이스를 통해 프로덕션 코드를 이해하는 시각과 관점을 보완 어느 한 사람이 과거에 경험했던 고민을 팀 차원으로 승격시켜서 모두의 자산으로 공유할 수 있다. @DisplayName 음료 1개 추가 테스트 (명시의 형태) → 음료 1개를 추가할 수 있다. (문장의 형태로 나열) ex) A 일때 B이면 C이다 테스트 행위에 대한 결과까지 기술하기. 도메인 용어를 사용하여 추상화된 내용을 담기. 메서드 자체의 관점보다 도메인 정책의 관점으로 생각하기 테스트의 현상을 중점으로 기술하지 말것. BDD Behavior Driven Development TDD에서 파생된 개발 방법. 함수 단위의 테스트에 집중하기보다, 시나리오에 기반한 ..

Layerd Architecture (관심사의 분리) Presentation Layer 외부 세계의 요청을 가장 먼저 받는 계층 파라미터에 대한 최소한의 검증을 수행한다. 넘겨온 데이터들에대한 Validation이 중요하다. Business Layer 비지니스 로직을 구현하는 역할 Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)을 통해 비지니스 로직을 전개 트랜잭션을 보장해야한다. Persistence Layer Data Access의 역할 비지니스 가공 로직이 포함되어서는 안된다. DATA CRUD에 대한 CRUD에만 집중한 레이어 @DataJpaTest //@SpringBootTest 보다 가벼움. JPA에 필요한 bean만 띄워줌 하위 계층은 상위 계층에대한 Data가 없어..

TEST Double Dummy : 아무것도 하지 않는 깡통 객체 Fake: 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체 (Ex. FakeRepository) Stub: 테스트에서 요청한것에대해 미리 준비한 결과를 제공하는 객체 정의하지않은 그 외에는 응답하지 않는다. Spy: Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체. 일부는 실제 객체처럼 동작시키고 일부만 Stubbing 할 수 있다. Mock: 행위에대한 기대를 정의하고, 그에 따른 동작을 하도록 만들어진 객체. Stub 과 Mock의 차이 Stub 은 상태 검증 어떠한 검증 이후 스텁의 상태에따라 검증 Mock은 행위 검증 Mock이 진행한 어떠한 행위에대한 중심으로 검증. Classicist VS M..

한 문단에 한 주제 하나의 메서드에대한 하나의 테스트에는 한 가지 주제가 들어가야한다. 한개 이상의 경우를 검증하는 테스트를 작성하지말자. 논리구조가 들어간 테스트를 지양하자. (ex. if문, 반복문) 무엇을 검증하는지 여러가지 논리구조들이 복잡하게 만들 수 있다. 완벽하게 제어하기 테스트시에 랜덤값, 외부 시스템에 연동하는 경우들에 대한 조건에대해 완벽하게 제어할 수 있어야한다. 랜덤값, 시간 등… 매개 변수로 예측하거나 검증시 어려운점이 포함 될 경우 매개변수값으로 받거나 랜덤값을 지정해 진행하는 테스트를 내가 완전하게 제어할 수 있어야한다 외부 시스템에 연동해 의존하는 경우 Mocking을 통한 Stubbing으로 외부 시스템를 테스트내에서 완전하게 제어할 수 있어야한다. 테스트 환경의 독립성을 ..

UnitTest 작은 코드 단위를 독립적으로 검증하는 테스트 클래스 , 메서드 검증속도가 빠르고 안정적이다. Junit 5 AssertJ 테스트 라이브러리 풍부한 API, 메서드 체이닝 지원. TEST CASE Test 세분화 하기 Happy Case 요구사항에 맞는 케이스 예외 케이스 요구사항에 들어나지않은 암묵적인 요구사항이 있었을 때 주문 갯수를 -1 로 입력한다거나 0개라거나 등등.. 예외적인 케이스 경계값 테스트가 중요하다. 범위 (이상,이하, 초과,미만) 구간, 날짜 등… 테스트하기 어려운 영역을 분리하기 테스트하기 어려운 영역을 외부로 분리해 테스트 작성시 외부값을 받아 테스트 진행을 한다. ex) 주문 기능에 정해진 영업시간에만 주문이 가능는 서비스가 있을 때 주문시간을 매개변수(외부값)로..

난 테스트 코드 작성을 좋아하기도하고 중요하게 생각한다. 왜냐면 녹색불이 뜨면 기분이좋다.... 그렇다보니 테스트 코드에 대해 여러가지로 공부하려 노력을하는데 어제 테스트 코드를 작성하기 어려운 메서드를 작성하게되어 Testable Code란 무엇일지 공부해봤다.. 우선 문제의 메서드 문제점 메서드의 역할과 책임이 다양하다. 이미지 검증도하고... uuid로 이름 변환도하고....S3로 이미지 업로드도 진행하고.... 해당 메서드의 테스트를 진행하려하니 참조하고있는 imageUploader 객체의 imageToS3의 메서드가 실행되지않아 테스트가 불가능해졌다... 테스트하기 좋은코드란 우선 역할과 책임이 단순 명료해야한다. 그렇기때문에 LayerArchitecture가 테스트 케이스에 이점을 가지고있는것..