애초에 TDD이야기 하기전에 본인의 코드에 테스트 넣는 방법테스트를 넣을때 자연스럽게 넣는법을 알아야됨 . 회귀 버그 방지유연한 설계로 개선 -> 테스트 쉽고 결정적이게 만들어 줌프로젝트가 뻣뻣한 설계를 가지고있으면 중간에 테스트를 넣어도 산으로가고 결국 실패얼마나 촘
간단한 계산기 코드를 리팩토링하면서 테스트를 해보자케이스문 분리라이브러리 부분은 몰랐던대 알아두자 이런식으로 덧셈 곱셉 뺄셈 나눗셈 테스트를 작성한다. + 예외 연산자외 다른게 들어왓을때입력 부분을 따로 분리입력받은 부분 테스트코드는 예전에 몰랐던건데 지금알아서 신기!
어떤 시스템이 제대로 동작하는지 검증하는 과정 인수테스트(체크리스트를 받아서 테스트) / 자동테스트(내가하는것)개발자가 저지르는 대표적인 실수인터페이스를 생각하지않고 구현체를 먼저만든다red단계에서 컴파일 코드만들고 테스트 실패확인 -> 그래서 개발자는 구현체 보다 인
사용자가 로그인할때마다 로그인한 시간 기록그런대 의존성이 숨겨져 있다.외부에서 이메소드가 클락을 사용하는지 모르기 때문어떤값이 들어가야되이런식으로 외부에 주입시키면테스트가 편해진다.의존성은 드러내면 좋다.userService login 마찬가지로테스트하기 힘들어짐의존성
전반적인 테스트 작성딱히 도움되는 파트는 아니었다.기본 레파지토리레파지토리 테스트는 알아지만 알아 두자기본 테스트 들 검증 방식이 특이하다 필드하나하나가아니라존재하는지 안하는지 잘생각해보면 그냥 연습이니까 이런식인거같다왜전체로 돌릴 때만 실패할까?동시성 제어가 안돼서
모두 중형 테스트가 되버린다ES같은 디비는 어떻게 실습할까?가장 먼저 배우는 구조디비 위주의 설계를 하게 된다.제일 아랫단인 영속성 객체부터 만들 생각을한다.주문 시스템 바로이런식으로 이런거 부터 생각을 한다.원래는 이런걸 파악을 먼저다그리고 도메인과 도메인의 관계를
이런 dto 클래스도 service 패키치에서 참조하는 거라도메인으로 이동그리고 이름에서 dto도 빼준다이전 강의에서 궁금햇던 부분이 풀렸따이런식으로 분리를 해서 사용하는구나괜찬은 구성같다허나지금 팀에 적용시키려면 팀원들을 설득시켜야할거 같은데 힘들거같다 ㅠㅠ테스트 구
이런식으로 도메인 객체를 만들어준다기존 마이바티스에서 jpa로 컨버팅 하는 프로젝트를할때모델 부분에 해당되는 객체인대 강의자는 이런식으로 Jpa엔티티 도메인 으로나눈다. 이런식으로 빌더로 관리를하고레파지토리도 이런식으로Post쪽도 마찬가지이런식으로 디비 엔티티에서 도메
당연하지 !준수해야되는 규칙? 룰 왜 굳이 이렇게까지 해야되지?아키텍처를 실현할수록 계속 불편해짐근대 아키텍처를 계속사용하고? 개선하는이유?꼭 써야되는 이유가 있따.그 이유를 찾고 구성원 모두가 공감해야됨. 아니면 장애물 덩어리이런식의 아키텍쳐의 목표 결과적으로 의존성