테스트코드_발자국4

통합 테스트여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트이다.단위 테스트만으로는 전체 기능의 신뢰성을 완전히 보장할 수 없기 때문에, 이를 보완하기 위해 수행된다. 통합테스트의 중요성단위 테스트의 한계 보완큰 기능 단위를 검증 테스트 코드 작성시 유의사항테스트 단위를 작게 유지한 번에 여러기능을 검증하면 원인 파악이 어려워짐 한 테스트에는 하나의 기능만 검증테스트마다 명확한 목적을 두고 하나의 기능만 검증해야 함테스트 환경의 독립성 보장테스트 간 실행 순서에 영향을 받지 않도록 독립적인 환경을 유지해야 함테스트 간 독립성 보장각 테스트는 독립적으로 실행되어야 하며, 다른 테스트의 결과나 상태에 의존해서는 안됨 private 메서드 테스트private 메서드는 직접 테스트 할 필요 없음테스트 대상은 항상 public이여야 함private 메서드는 해당 클래스를 사용하는 public 메서드를 통해 간접적으로 검증됨

테스트코드_발자국3

🙂 강의 내용@Transactional(readOnly = true)readOnly = true로 설정을 한다는 것을 읽기 전용이라는 뜻CRUD에서 CUD는 동작하지 않음. R만 작동함JPA에서 CUD 스냅샷 저장, 변경을 감지하지 않아 성능이 향상됨readOnly = true로 걸어 놓고 CUD 하는 부분에는 따로 트랙잭션 어노테이션을 달아놓을 것을 추천 @SpringBootTestfull application config를 로드해서 통합 테스트를 진행하기 위한 어노테이션테스트할 때마다 DB가 롤백 되지 않음DataSource bean을 그대로 사용하기 때문에 in-memory, 로컬, 외부 상관없이 DB 사용해 테스트가 실행됨 @DataJpaTest오직 JPA 컴포넌트만을 테스트하기 위한 어노테이션@Transactional 어노테이션을 포함해 자동으로 롤백이 됨설정해놓은 DB가 아닌 in-memory DB를 활용해서 테스트가 실행됨 🙂 Day 11 미션 회고어떤 기능들을 우선순위로 두어 테스트를 작성해야 할 지 처음에 막막했다.코드를 읽어보면서 제일 작은 단위의 기능 또는 단순히 반환만 해주는 코드도 테스트를 작성해야 하는건지 고민을 많이 했다.미션 이후 강의를 들으면서 아주 사소한 것이라도 별 것 아닌 기능들에도 모두 코드를 작성해야 한다는 것을 알게되었다.

클린코드 발자국2

테스트 코드를 왜 작성해야하는가??빠른 피드백자동화안정감 Junit이란?단위 테스트를 위한 테스트 프레임워크AssertJ테스트 코드 작성을 원활하게 돕는 테스트 라이브러리 테스트 코드는 어떻게 작성해야 하나??단위 테스트를 해야함단위 테스트란 클래스 또는 메서드 단위로 작은 코드 단위를 독립적으로 테스트하는 방법이다. 테스트 케이스 세분화하기해피 케이스예외 케이스경계값 테스트 테스트하기 어려운 영역 구분하고 분리이 부분은 나도 테스트 코드 작성할 때 고민이긴 했다어려운 영역을 구분하고 분리 입,출력 등으로 TDD안해본 것이라 쫌 어렵긴 함선 기능 구현, 후 테스트 작성은 특정 테스트 케이스만 검증할 가능성 있고 그로 인해 잘못된 구현을 늦게 발견할 수 있음선 테스트 작성, 후 기능 구현은 복잡도가 낮은, 테스트 가능한 코드로 구현할 수 있게 함 쉽게 발견하기 어려운 엣지(Edge) 케이스를 놓치지 않게 해줌구현에 대한 빠른 피드백을 받을 수 있음과감한 리팩토링이 가능해짐

클린코드_발자국1

이름 짓기 포인트단수, 복수 구분하기이름 줄이지 않기cnt(x) -> count(O)단, 관용어처럼 많은 사람들이 사용하는 것 정도는 ok은어, 방언 사용하지 않기좋은 코드를 보고 습득하기비슷한 상황에서 자주 사용하는 단어, 개념 습득(ex. pool, candidate, threshold etc,,) 매직넘버, 매직스트링: 의미를 갖고 있지만, 상수로 추출되지 않은 숫자, 문자열 등을 뜻한다.=> 상수 추출로 이름을 짓고 의미를 부여함으로써 가독성과 유지보수성이 좋아진다.ex) 2147483647 => IntegerMaxValue (자바) depth 줄이기 - 중첩 분기문, 중첩 반복문추상화를 통한 사고 과정의 depth를 줄이는 것이 중요 Optional꼭 필요한 상황에서 반환 타입에 사용Optional을 파라미터로 받지 않도록 하기Optional을 반환받았을 시 최대한 빠르게 해소하기Optional 해소 방법분기문을 만드는 isPresent()-get 대신 풍부한 API 사용orElse(), orElseGet(), orElseThrow()의 차이 숙지 SOLID단일 책임 원칙(Single Responsibility, SRP) ↪ 하나의 클래스는 한개의 기능만 가지고 있어야 한다.개방-폐쇄 원칙(Open-Closed Principle, OCP) ↪ 기능을 수정하거나 추가할 때 기존 코드를 변경하면 안된다. 즉, 한 기능을 수정하거나 추가할 때 다른 코드를 줄줄이 변경하는 경우가 없어야 한다.리스코프 치환 원칙(Liskov Substitution, LSP) ↪ 상속되는 객체는 반드시 부모 객체를 완전히 대체할 수 있어야 한다.인터페이스 분리 원칙(Interface Segregation, ISP) ↪ 여러개의 구체적인 인터페이스를 사용하더라도 자신이 사용하지 않는 인터페이스로부터 영향받지 않게 자신이 사용하는 메서드에만 의존해야한다.의존 역전 원칙(Dependency Inversion, DIP) ↪ 무언가에 의존할 때 구체화된 클래스가 아닌 추상 클래스나 인터페이스에 의존해야한다. 강의 참고함