[워밍업 클럽 4기] 4주차 발자국 남기기

안정성과 확실성Practical Testing드디어 완강!!올바른 테스트코드를 작성하는 법을 배우고 실무에서 남몰래 적용해보고 있는데 확실성과 안도감이 생겨 퇴근할 때 기쁘기까지 했다. 다음 프로젝트에서는 팀 단위로 적용해보면 좋을 것 같다.미션 Day 16 미션Layer 별 특징과 테스트 방법에 대해서 나름 정리해보았다. 완강한 지금 테스트 환경도 통합하고 나니 내가 작성한 애플리케이션을 Layer 별로 나눠서 작성하고 테스트하고 검증까지 마친 기분이라 뿌듯했다. Day 18 미션BDD 스타일에 맞게 테스트 코드를 작성하고 각 테스트 객체에 대해 공부하였다. @MockBean 애노테이션은 deprecated 된 것 같은데 방안에 대해서 더 공부해 봐야할 것 같다.이젠 테스트 코드 작성하고 싶어서 API를 만드는 지경이 되어버린 것 같다. api 인터페이스 작성 -> 필요 객체 작성 -> 테스트 인터페이스 작성 -> 실제 구현 -> 테스트 코드 작성 및 검증 순으로 진행하여야 겠다. 혼자 강의만 듣고 공부했다면 이정도로 와닿지 않았을 것 같다. 다음 기수에도 좋은 강의를 열심히 듣도록 참여해야 겠다.

[워밍업 클럽 4기] Day 18 미션

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이Mock - 단순 Mock 객체 생성 용, 단위 테스트에 자주 사용, 행위 검증용, when().thenReturn() 사용 MockBean - 스프링 컨테이너에 등록된 빈 대체용 MockSpy - 실제 객체를 감싸서 일부만 Stub 가능, 나머지는 원래대로 동작, 상태 검증용, doReturn().when() 사용 SpyBean - 스프링 컨테이너에 Spy 객체 등록InjectMocks - Mock/Spy 객체를 주입받을 실제 객체 생성 @BeforeEach void setUp() { 1-1. 사용자 생성에 필요한 내용 준비 (2-1, 3-1) 1-2. 사용자 생성 (2-2, 3-2) 1-3. 게시물 생성에 필요한 내용 준비 (2-3, 3-5) 1-4. 게시물 생성 (2-4, 3-6) } @DisplayName("사용자가 댓글을 작성할 수 있다.") @Test void writeComment() { // given 1-5. 댓글 생성에 필요한 내용 준비 // when 1-6. 댓글 생성 // then 검증 } @DisplayName("사용자가 댓글을 수정할 수 있다.") @Test void updateComment() { // given 2-5. 댓글 생성에 필요한 내용 준비 2-6. 댓글 생성 // when 2-7. 댓글 수정 // then 검증 } @DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given 3-3. 사용자2 생성에 필요한 내용 준비 3-4. 사용자2 생성 3-7. 사용자1의 댓글 생성에 필요한 내용 준비 3-8. 사용자1의 댓글 생성 // when 3-9. 사용자2가 사용자1의 댓글 수정 시도 // then 검증 }

[워밍업 클럽 4기] Day 16 미션 - Layer 별 특징과 테스트 방법

Layer 별 특징과 테스트 방법관심사의 분리에 따라 Layer를 나눌 수 있고 아래와 같이 나뉜다.Persistence Layer Data Access의 역할을 하는 레이어(데이터 CRUD에만 집중)비즈니스 의사결정 로직은 포함되지 않아야 함@Transactional 애노테이션이 포함되어있는 @DataJpaTest를 통해 비교적 가볍게 테스트 가능Business LayerPersistence Layer와 상호작용을 하며 비즈니스 로직을 전개시킴Transaction 경계에 대해 인지하고 실제 코드에서 적용하며 테스트에서는 @SpringBootTest로 진행 가능Presentation Layer외부 세계의 요청을 가장 먼저 받는 계층으로 파라미터에 대한 검증을 수행해야 함사용하는 service, repository 관련 레이어들은 mock으로 처리하며 @WebMvcTest를 통해 진행파라미터 검증은 주로 @Valid, @RequestParam, @PathVariable 등으로 처리됨

[워밍업 클럽 4기] 3주차 발자국 남기기

나는 오늘도 성장한다Practical Testing이번 한 주는 직접 비즈니스 로직을 짜면서 테스트코드를 작성해보는 시간을 가졌다.강의 제작 기간이 Readable Code 보다 이전이라 그런지 차근차근 따라가며 진행할 수 있어 좋았다.실제적으로 고민하는 과정을 따라가며 작성하다보니 얼른 내 프로젝트에도 적용하고 싶었다. Day 11 미션이미 완성된 코드에 테스트 코드를 작성하는 건 역시 놓치는 부분이 많은 것 같다.하나의 메서드를 작성하며 테스트 코드도 작성해야 해당 테스트의 정상 동작, 예외 처리, 예측가능한 오류에 대해 테스트하고 안정성에 대한 검증 후에 다음 프로세스를 진행할 수 있을 것 같다.

[워밍업 클럽 4기] 2주차 발자국 남기기

핑계지만 퇴근 후 시간만 할애해서 완강을 하기엔 너무 힘들 것 같다하지만 강의가 재밌어서 출퇴근길에도, 퇴근 후에도, 주말에도 몰입하여 진도를 최대한 따라가려 노력 중이다.클린코드에 대해서 뒤늦게 안 내가 바보같지만 지금이라도 알게되어서 다행이라고 생각한다. 강사님 정말 감사합니다. 이해가 쏙쏙 됩니다. 강제적으로 공부하게 해준 인프런, 언제나 최고라고 생각합니다. Readable Code지난 주에 멈춰있던 나라 이번주에는 질주했어야 했다. 추상과 객체지향이 가장 중요한 키워드라고 생각한다.나와 동료 개발자, 후대의 개발자를 위해 클린코드를 지향해야 하고 그러기 위해서는 도메인에 대한 이해가 선수되어야 하며 이를 바탕으로 중요 정보를 가려내어 추상할 수 있어야 한다.추상의 과정에서 SOLID, 객체지향의 원칙들을 지키며 작성해 나가고 사고의 깊이를 줄이는 방식으로 코드를 작성하여 인지적 경제성이 좋은 방향으로 나아가야 한다. 리팩토링을 거듭하다보니 테스트 코드가 너무 필요하다 느껴진다. 다음 강의도 열심히 들어야겠다는 마음 가짐을 단단히 심어주시는 것 같다. Day 7 미션리팩토링할 곳이 많이 보였지만 시간에 급급하여 할 수 있는 것들만 진행하였다.개발자의 상상력을 동원해 오버 엔지니어링 되지는 않았는지 체크하는 게 가장 어려웠다.

[워밍업 클럽 4기] 1주차 발자국 남기기

폭풍같던 첫째주 여러가지 일은 다 해내기란 힘든 것 같다. 다음주에는 좀더 계획을 세워 노는 것도, 공부하는 것도 정해진만큼 해내야 겠다.Readable Code - 섹션 5까지사이드 프로젝트를 구현하면서 강의 내용과 같이 정말로 이름 붙이기가 가장 고민되었던 것 같다. 구현 중이라 티켓마다 리팩토링을 하며 가독성 좋은 코드를 작성하려 노력중이다. 추상, 논리적 사고 흐름, 객체 지향 패러다임 등 처음 듣는 낯선 단어는 아니지만 배우고 혼자 생각하며 익히고, 그걸 적용하기까지 많은 시간이 걸렸던 것 같다. 가독성 좋은 코드를 위해선 핵심만 보여주는 추상, 사고의 깊이를 줄이기 위한 구조, 구조적이고 재사용 가능한 객체 지향 설계가 중요하다는 것을 깨닳았다. 미션Day2항상 느꼈던 거지만 추상을 위해선 세부적인 것을 잘 알아야 추상을 통해 간략화할 수 있는 것 같다.세부적인 것들을 자세히 공부하고 추상화하여 머릿속에 입력해야지Day4역시 아는 것과 실천하는 것은 다르다는 것을 알게되었다. 다른 사람의 관점에서 한번 더 생각해야 가독성 좋은 코드가 나오는 것 같다.고민이될 때는 기초로, 여러 고민되는 지점이 있을 때 의외로 SOLID가 도움이 많이 되었다.

[워밍업 클럽 4기] Day4 미션 - SOLID, 논리 사고 흐름

코드 리팩토링 public boolean validateOrder(Order order) { if (order.getItems().isEmpty()) { log.info("주문 항목이 없습니다."); return false; } if (order.getTotalPrice() Early return을 활용하여 바로 답해주자 (else 지양)부정어구를 적게 사용할 수 있는 방법이 있으면 변경하자논리의 깊이를 줄여보자 SOLID- SRP : 클래스는 하나의 책임만 가져야 한다.- OCP : 확장에는 열려 있고, 변경에는 닫혀 있어야 한다.- LSP : 자식 클래스는 부모 클래스를 대체할 수 있어야 한다.- ISP : 인터페이스는 클라이언트가 사용하지 않는 메서드에 의존하지 않아야 한다.- DIP : 고수준 모듈은 저수준 모듈에 의존하지 않고, 둘 다 추상에 의존해야 한다. referenceReadable Code: 읽기 좋은 코드를 작성하는 사고법

[워밍업 클럽 4기] Day2 미션 - 추상과 구체

Readable Code 초반을 학습하고 있는데하나의 단어를 설명하더라도 자세히, 타당한 근거를 제시해 주셔서 두번 이해하려 노력하지 않아도 되어서 좋다.추상과 구체를 현실 세계의 나를 예로 들어 프론트를 공부해야 할 때 vue에 대해 공부 방법을 세울 수 있을 것 같다. vue를 생각해보니 추상적으로 컴포넌트의 조합으로 구축하는 프레임워크라는 생각이 든다.이런 큰 그림을 생각해두고 구체화 시켜 세부적으로템플릿, 데이터, 메서드로 구현한 재사용 가능한 단위인 컴포넌트를 활용해 여러 컴포넌트들을 조합하여 반응형 사용자 인터페이스를 정의하는 것이라고 설명할 수도 있을 것 같다. 위처럼 구체화시켰으니 템플릿, 데이터, 메서드에 대해 공부하고 활용하여 컴포넌트를 만들고 조합하는 과정을 익히는 것을공부 방향으로 정하고 빠른 시일 내에 시작해 보아야 겠다.