TDD

변화가 생기는 매순간마다 발생할 수 있는 모든 Case를 고려해야 한다.변화가 생기는 매순간마다 모든 팀원이 동일한 고민을 해야한다.빠르게 변화하는 소프트웨어의 안정성을 보장할 수 없다.프로덕션 코드의 안정성을 제공하기 힘들다테스트 코드 자체가 유지보수하기 어려운, 새

작은 코드 단위를 독립적으로 검증하는 테스트검증 속도가 빠르고 안정적이다.해피 케이스예외 케이스→ 경계값 테스트범위(이상, 이하, 초과, 미만), 구간, 날짜 등 현재 시간에 의존하여 테스트가 실패하는 경우, 성공하는 경우 발생ProductionCodeTestCode

프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현과정을 주도하도록 하는 방법론테스트 자체의 누락 가능성특정 테스트 케이스(해피 케이스)만 검증할 가능성잘못된 구현을 다소 늦게 발견할 가능성복잡도가 낮은(유연하고, 유지보수가 쉬운), 테스트 가능한 코드로 구현

명사의 나열보다 문장으로 작성테스트 행위에 대한 결과까지 기술하기 도메인 용어를 사용하여 한층 추상화된 내용을 담기테스트의 현상(실패 or 성공)을 중점으로 기술하지 말것개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준을 권장Given: 시나리오 진행에

OrderService createOrder 구현 구현과정 createOrder 메서드 생성 createOrder에 필요한 request, response dto 생성 return을 null로 하고 임시로 테스트 구현 -> Red, Green, Blue 중 Red 과

TDD를 위해 대략적인 틀만 잡은 뒤 테스트코드가 실행되는지 판단한다.이후 코드를 구현하고, 코드 구현과정중 단위테스트를 진행해가며 Green, Blue과정 진행단순히 테스트 코드 실행을 위한 Red 케이스Stock, StockRepository, StockTest 생

새로운 상품이 등록되면 가장 최근 상품번호 + 1 한값을 ProductNumber로 가지는 데이터를 생성한다.DB조회를 진행해 최근 상품번호 조회 필요상품이 정상적으로 생성되었을때, 상품을 생성할때 상품이 없는경우 두가지 경우 테스트얕은 수준의 Service테스트는 R

Mocking을 언제 어디서 사용해야 하는가?

예상 반환타입인 boolean의 default(false) 값을 리턴한다.Primitive 타입인 경우 Primitive타입의 기본값을 리턴인스턴스로 반환하는 경우는 null을 기본으로 리턴한다.Mockito의 verify를 이용해 검증을 진행할 수 있다.Mockito

BDD 구조에 맞게 Mockito 문법을 변화시킨 것이름만 바꾼것일뿐 동작은 기존 Mockito와 동일하다기존given절이지만 when으로 시작하는 Mockito 문법이 어색하다.BDDMocktio 사용

테스트 코드 하나에는 하나의 주제가 있어야 한다.반복문이나 분기와 같은 논리구조가 나타나지 않아야 한다.~ 하나의 DisplayName으로 만들수가 있는가?잘못된 코드for 문과 if문을 활용해 여러가지 상황의 ProductType을 검사하고 있다.수정된 코드개발자가

TDD Tips (1)의 한문단에 한 주제 규칙으로 인해 많아진 테스트코드들의 중복을 제거할수있는 방법기존 코드@CsvSource 사용@CsvSource안에 간단하게 키밸류 형태로 넣어준다.각각의 타입에 맞는 파라미터를 통해 메서드로 주입@MethodSource 사용@