인프런 워밍업 클럽 후기 (2기 백엔드 클린코드, 테스트 코드)

인프런 워밍업 클럽 수료! 1. 워밍업 클럽 참여! 인프런의 효과적인 마케팅, 새로운 기술 학습에 대한 열정으로 다양한 강의를 구매했다.하지만, 완강하지 못한 강의가 쌓이기 시작했다.인프런에서 워밍업 클럽이라는 온라인 스터디를 제공해준다는 글을 보았다.공부도 하고, 혜택도 있다니 안 할 이유가 없어서 즉시 신청 했다.나는 평소에 관심이 있던, 클린코드와 테스트 코드 주제를 신청했다. 2. 1달 동안 강의 지옥(천국) 1달 동안 들어야 하는 강의는 2가지 강의였다.클린코드(14시간), 테스트코드(12시간) 이 정도는 쉽게 완강하겠다는 생각이 있었다.역시 예상은 틀렸고, 매주 정해진 스케줄과 미션을 완료하는 데 빠듯했다. (하지만, 수료했다.)클린 코드의 경우, 객체 지향 설계 원칙에 따라 직접 2가지 프로젝트를 리팩토링하는 과정으로 진행되었다.테스트 코드의 경우, 직접 작은 프로젝트에 대해 테스트 코드를 작성하는 과정으로 진행되었다.매주 정해진 미션, 중간 점검 등이 있어서 자칫 느슨해 질 수 있는 온라인 스터디에 지속성을 더해주었다.3. 회고 스스로 1달동안 열심히 했냐고 물어봤을 때, 열심히 했다고 대답이 나왔다.모든 미션과 강의를 완주했기에 보람과 뿌듯함이 있었다.그럼에도 불구하고, 스스로에게 아쉬움도 있다.멘토님이 중간점검과 특별 점검을 통해 직접 미션 리뷰(코드리뷰)를 해주시고, 개발 관련 질문을 받았다.다른 스터디원들은 미션에 대해 적극적으로 코드 리뷰를 신청하고 질문을 하셨다.나는 안했다. 스스로의 과제에 대해 미흡하다고 느꼈고, 공지 사항을 놓치기도 하였다.그렇다면, 다음 워밍업 클럽이 열린다면 신청할 것 인가?나는 신청할 것 같다.그리고 이 글을 다시 보며, 부족했던 점을 돌아보고 나에게 더 도움이 되는 스터디가 될 수 있도록 노력해보고 싶다.오프라인 수료식 후기 내향적이지만, 용기내서 오프라인 수료식에 참여했다.늦은 시간임에도, 오프라인 수료식을 위해 노력해주시는 인프런 관계자 분들에게 감사했다. 또한, 워밍업 클럽 수료생들로부터 많은 에너지를 충전할 수 있었다.그리고, 준비해주신 피자 너무 맛있었다. 어디 브랜드인지 궁금하다.

[워밍업 클럽 스터디 2기 백엔드(클린코드, 테스트코드)] 4주차 발자국

4주차 강의 : Mock을 마주하는 자세, 더 나은 테스트를 작성하기 위한 구체적 조언, 부록(Spring Rest Docs) 요약1. 테스트 환경에서 모든 빈을 제어하기 힘들다. -> 테스트 더블(@Mock, @Spy 의 필요성)2. 테스트코드도 코드다. 따라서, 관리되어야 한다.3. 테스트 코드 작성으로 작성하기 귀찮은 개발 문서까지 이어진다면?(어렵고, 귀찮은 과정을 통해) 강의 내용 @Mock을 마주하는 자세테스트 코드를 작성하다 보면, 의존성 주입이 필요해진다.테스트 하고자 기능을 제외한 빈의 생성은 불필요하다는 전제에서, 테스트 더블(대역) 활용 필요성 테스트 더블 역할을 생성할 수 있는 어노테이션@Mock, @Spy, @InjectMocks 운영 환경에서 테스트, 특정 조건에서 효율적인 테스트 (Classicist VS Mockist)더 나은 테스트를 위한 구체적 조언프로그래밍 언어도 언어이기에, 한 문단에는 한 주제를 갖는 것이 좋다.테스트는 환경 그리고 테스트 간의 독립성이 보장되어야 한다.테스트 후 데이터는 클렌징 되어야 하고부록테스트를 작성했다면, 스프링을 활용하여 개발 문서를 작성할 수 있다.Spring Rest Docs 통해 개발 문서를 작성할 수 있다.미션 1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 정리2. 테스트 코드의 배치강의에서 학습한 테스트 더블 어노테이션의 차이에 대해 정리하였다.테스트 코드의 작성 순서를 정리해보면서, 어떻게 테스트를 효율적으로 작성해 나갈 것인지 생각해 볼 수 있었다. 4주차 회고 - 4주는 짧지만, 긴 시간이다. 완강은 힘들다. 인프런 워밍업 클럽이라는 , 강제성이 생기면서 4주간 2개의 강의를 완강할 수 있었다. 코드를 잘 작성하는 것 에 대해 이해할 수 있었다.클린코드, Reasonable code에 대해 구체적으로 생각을 갖게 되었다.강의를 듣고, 리팩토링을 진행하면서 이 정도까지 해야하나? 라는 생각이 들기도 했다.그렇지만, 완성한 후 다시 코드를 읽어 보니 일단 나는 이해하기가 쉽다.테스트 코드작성에 대해 자신감을 갖게 되었다.테스트코드가 중요하다, 필요하다는 이야기를 들어서 세뇌되어 있었지만 막막했다.어떻게 작성해야 하는 지 가늠이 되지 않았다. (강의 전)이제는 테스트코드 작성에 자신감이 생겼다. (강의 후)결국 코드는 실전이라는 생각을 워밍업 클럽 마지막 주차에 다시 생각하게 된다.자신감이 생겼을 때, 더 연습하고 성장해야겠다.

워밍업 클럽 2기 백엔드 클린코드&테스트 Day 18 미션

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이 @Mock, @Spy 차이- '가짜'이냐 '진짜'이냐의 차이- @Spy' 진짜' 객체라면, 객체 내부의 메서드가 실행된다.- @Mock '가짜' 객체라면, 객체 내부의 메서드가 실행되지 않는다. @Mock과 @MockBean 차이@Mock은 Spring과 독립적으로, 단위 테스트에서 객체의 특정 메서드를 모킹할 때 사용!@MockBean은 Spring Boot 통합 테스트나 Spring의 의존성 주입이 필요한 상황에서 사용되며, Spring 컨텍스트에 Mock 객체를 주입하여 해당 객체를 사용! @Spy: Mockito 스파이 객체를 테스트 클래스 내부에서만 사용하며, Spring 컨텍스트와는 무관합니다. 단위 테스트에서 사용됩니다.@SpyBean: Spring 애플리케이션 컨텍스트에 스파이 객체를 주입하여 Spring의 Bean과 상호작용할 수 있게 합니다. Spring 통합 테스트에서 사용됩니다. @InjectMocks@Mock 객체에 필요한 의존성을 주입해주는 역할을 수행한다. 2. 테스트 코드 문서화핵심은 중복 제거가 아닌, 도메인사용자, 게시물은 간접적이므로 setUp, 댓글은 직접적으로 given절@BeforeEach void setUp() { 1,2,3-1. 사용자 생성에 필요한 내용 준비 1,2,3-2. 사용자 생성 1,2,3-3. 게시물 생성에 필요한 내용 준비 1,2.3-4. 게시물 생성 } @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 검증 }

Layered Architecture 구조의 테스트 작성 방법

인프런 워밍업 클럽 백엔드 2기 클린코드, 테스트 코드 참여 미션 수행 중 하나입니다!관련 강의 :Practical Testing: 실용적인 테스트 가이드( https://www.inflearn.com/course/practical-testing-%EC%8B%A4%EC%9A%A9%EC%A0%81%EC%9D%B8-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EC%9D%B4%EB%93%9C/dashboard)1. Layered Architecture ? 소프트웨어 개발 방법 중 하나로, 계층(Layer) 의 수에 따라 N-tier Architecture 부르기도 한다.계층은 어떻게 나누는 것인가? - 책임에 따라서 나눈다.강의에서는 3-tier Architecture 기준으로 나누었다. (Persistence, Business, Prsentation) 2. Layer(Persistence, Business, Prsentation) 1. Persistence Layer 책임 : 도메인(객체)의 생성과 검증 도메인의 생성과 관련된 책임을 가진 계층이다.애플리케이션에서 생성한 객체(Domain)이 데이터베이스에 올바르게 저장되는지 검증하는 과정이 필요하다. Persistent Layer 는 객체가 어떻게 저장되고, 어떤 파라미터를 필요로하는 지 이해할 수 있는 계층이다.테스트 코드 작성을 통해, Business 계층에서 사용될 객체들에 대해 이해를 가질 수 있는 계층이라 생각한다.뒤에 올 Business, Presentation 계층의 작성을 위한 기본적인 토대를 제공하는 계층이다.따라서, 이어질 계층에서 도메인에 대한 고민을 할 필요 없도록 테스트 코드를 작성해주는 것이 필요하다고 생각한다. 2. Business Layer 책임 : 도메인의 비지니스 로직 수행 객체의 생성과 검증이 완료된 토대에서, 서비스의 로직 을 수행하는 책임을 가진 계층이다.Persistent Layer에서 검증되고, 생성된 객체가 수행하는 책임을 검증하는 계층이라고 볼 수 있다.그렇기에, 코드의 양이 많고 테스트 코드 작성도 복잡해진다.Service(Business)은 Persistent(Repository) 의존한다. 즉 2개의 계층이 테스트에 필요해진다.중요하다고 생각하는 지점은, 이 계층은 비지니스 로직 에 집중해야 하는 계층이라는 점이다.객체의 생성과 관련된 코드는 감추고 , 로직과 관련된 코드는 표현되어야 한다.강의를 들으면서, 책임을 어떻게 분리할 것인가? 라는 의문이 생길 수 있다고 생각했다.비지니스 계층을 작성하면서, 도메인과 비지니스 그리고 로직과 로직 사이의 리팩토링이 많이 이루어 질 수 있다고 생각! 3. Presentation Layer책임 : 생성과 로직이 처리된 데이터의 출력 2 계층에서 생성되고, 처리된 데이터가 올바르게 생성되거나 프런트엔드에 올바르게 반환되는지 확인하는 책임을 가진 계층Business 계층에 의존한다. Business Layer 테스트에서 주의해야 할 점과 같이, Presentation Layer 검증에 집중해야 한다.하지만, Business Layer의 특징은 복잡하다는 것이 있었다. 대체(Mock)개념의 필요성Presentation Layer 계층의 테스트에 집중하기 위해 Mockito 를 활용하여, 가짜 객체를 생성하고 테스트에 도입한다.결국 데이터의 바인딩(Binding), 맵핑(Mapping) 에 집중해야 한다.API를 호출하면, 의도된 매개 변수를 받고 올바른 응답을 생성하는 과정을 검증할 수 있어야 한다.

[워밍업 클럽 스터디 2기 백엔드(클린코드, 테스트코드)] 3주차 발자국

3주차 강의 : 단위 테스트, TDD | 테스트는 [ ] 다, Spring & JPA 기반 테스트 요약1. 테스트 코드가 무엇이고, 왜 해야하는지2. Spring MVC, JPA 기반 테스트는 어떻게 작성하는지3. 테스트 코드 작성하는 것이 얼마나 중요한(귀찮은) 일인지강의 내용 단위 테스트테스트 코드를 작성하지 않는 환경의 테스트 (수동 테스트)테스트 코드를 통한 테스트테스트 코드 작성 시 고민해야 할 부분테스트 케이스를 어떻게 나눌 것인가? (해피, 예외)테스트 하기 어려운 영역은 어떻게 분리할 것인가? 2 .TDD | 테스트는 [] 다.TDD(Test-Driven-Development)란?테스트 코드를 작성 방법의 조언(DisplayName 작성, BDD 스타일)테스트는 경계값 테스트를 하는 것이 좋다. Spring & JPA 기반 테스트레이어드 아키텍쳐, JPA에 대해Persistent-Layer TestRepository 계층을 테스트한다.쿼리 실행을 통해 기대한 결과를 반환하는 지 테스트Business-Layer TestService 계층 테스트서비스 계층을 위해서는, 통합 테스트가 필요할 수 있다.SpringbootTest, DataJpa 테스트의 차이테스트 계층에서의 @Transactional 사용 시 주의해야 할 사항Stream()의 활용Presentation-Layer Test Mockito를 활용한 컨트롤러 서비스 코드 작성프런트엔드의 응답, 예외 처리Controller, Service 계층의 의존성 해결미션 - Readable Code 에서 작성한 코드의 테스트 코드 작성해보기이전 강의에서 리팩토링한 코드의 테스트 코드를 작성했다.3가지 클래스의 7가지 테스트 케이스를 작성하는 것이 과제! 테스트 코드를 작성하는 것이 어려웠는데, 돌아보면 기존 코드(지뢰찾기, 스터디카페)에 대한 이해 부족에서 기인그렇기에 이번 미션(테스트 코드를 작성)을 통해 좋았던 점은, 기존 코드의 이해 3주차 회고 - 테스트 코드에 대한 생각이 바뀌었다. Java, Spring을 인프런을 통해 공부했기에, 테스트 코드가 중요하고, 좋다는 것은 알고 있었다.강의 초반에 우빈님이 테스트 코드는 귀찮은 것 이라고 정의한 적이 있었던 것 같은데, 공감되었다.하나의 객체에서 추가 요건으로 메서드 추가 된다면, 즉시 테스트 코드를 추가해야 한다. (귀찮다.)또한, 테스트 코드가 개발자에게 도움이 되려면, 꼼꼼하게, 잘 작성해야 한다. (@Transactional, 예외 케이스)

[워밍업 클럽 스터디 2기 백엔드(클린코드, 테스트코드)] 2주차 발자국

워밍업 클럽 스터디 2기 백엔드 2주차 발자국 강의 내용요약 : 1주차에 배운 내용을 바탕으로 읽기 좋은 코드를 작성해보자.. Section 5 - 객체 지향 적용하기Section 6 - 코드 다듬기Section 7 - 리팩토링 연습 강의 내용Value Object값 객체 활용상대 위치, 셀 등 기존의 원시값을 객체 값으로 리팩토링 하는 과정이번 강의에서 가장 어려웠고, 실무에 어떻게 적용할 수 있을지 고민 되었던 강의반복 되거나, 대체 될 수 있는 값을 객체로 재정의하고 기존 코드를 리팩토링하는 과정인데, 간단할 거라고 생각했는데 생각보다 어려웠다. 미션스터디카페 회원 시스템 리팩토링 회고이번 주차의 핵심은 실습 이라고 생각이 들었다. 이론과 실제는 다르다는 것을 느끼는 한 주였다.1주차 강의를 들으면서 강의 내용을 스스로 이해 했다고 생각했다.막상 2주차 미션인 스터디카페 코드 리팩토링을 수행하면서, 부족함을 느꼈다.부족하다고 생각하는 부분은 1주차 강의 내용에 갇혀있다는 것다시 말하면, 스터디카페 미션을 수행하면서 나의 생각과 고민이 아닌 1주차에 했던 내용을 단순 반복하고 있다는 느낌이 들었다. 스스로 응용 하지 못하고 있다는 생각이 들었다.이러한 이유에는 여러 요인이 있겠지만, 가장 중요한 것은 내가 시간 분배를 잘 하지 못했던 것 때문이라고 생각한다.미션 수행에 더 많은 시간을 할애했어야 했는데, 사실 강의 따라 듣기도 바빴다.

[워밍업 클럽 스터디 2기 백엔드(클린코드, 테스트코드)] 1주차 발자국

1주차 강의섹션 1. 추상과 구체섹션 2. 논리, 사고의 흐름 | 객체 지향 패러다임섹션 3. 객체 지향 패러다임 (SOLID)요약 : 좋은 코드(클린코드)를 작성하기 위한 도구와 사용 방법을 학습 강의 내용추상과 구체 (클린코드의 목적과 도구)논리, 사고의 흐름 우리는 코드를 읽는 시간이 더 많다.따라서, 코드는 쉽게 읽히고 이해되어야 한다.이를 위해, 우리는 추상, 구체 를 이해하고 분리해야 한다.메서드 작성, 파라미터 선언, 반환값 고민, 매직 스트링 등 좋은 코드 작성을 위한 고민과 도구를 학습조기 리턴, 공백 라인, 부정어 등 이해하기 쉬운 코드 작성을 위해 조심해야 하는 부분 학습 한번쯤 들어보거나, 읽어본 이야기다. 그렇지만, 현업에서 개발하면서 시간을 핑계로, 선배들이 좋게 보지 않는다는 이유로 실무 개발과 공부한 내용을 분리해서 개발해왔다. 그렇기에, 실제 코드를 바탕으로 고민하고 코드를 작성해보는 경험이 좋았다. 개발자는 고민하고, 코드를 직접 작성해봐야 뭐가 된다는 것을 새삼 느낄 수 있었다. 객체 지향 패러다임단일 책임 원칙객체의 변경 기준은 책임이다.책임이 단일하지 않다면, 변경의 기준도 단일하지 않다.이로 인해 객체의 코드 변경의 원칙이 무너진다. 코드를 읽고, 객체를 사용해야 하는 입장에서 어려움을 겪게 된다.개방 / 폐쇄 원칙책임이 과중히 부과되어서는 안된다.즉 객체는 자신의 책임에 대해서는 기능을 확장할 수 있지만, 자신이 아닌 책임에 대해서는 영향을 받으면 안된다.현재의 책임이 구체인지 추상인지 고민하고, 구체라면 추상화와 다형성을 활용해서 원칙을 지킬 수 있다.리스코프 치환 원칙 사용하는 입장에서 부모 클래스와 자식 클래스의 차이를 알지 못해야 한다.즉 슈퍼 클래스는 불필요한 기능을 상속해서는 안된다. 객체의 상속 사용시 주의해야 할 것 같다.인터페이스 분리 원칙책임을 명확하게 갖는 것은, 인터페이스도 예외가 아니다.인터페이스는 추상화, 다형성의 중요한 도구인 동시에 책임을 갖는다.의존성 역전 원칙기능은 변하고, 요구사항은 추가된다.그렇기에 고수준 모듈은 구체(저수준 모둘)를 참조하는 것이 아니라 추상에 의존해야 한다.새로운 요구 사항이 추가되고, 기능이 변경된다고 하더라도 추상에 의존한다면 코드의 변경 범위를 최소화 할 수 있다 미션 : 배운 내용을 바탕으로 고민해보기미션1. 추상과 구체 사례 예시 제출미션2. 과제 코드 리팩토링 제출미션은 강의를 학습한 내용을 적용해보는 방향으로 접근했다.특히, 고민 해보는 것을 중요하게 생각했다.과거에도 강의를 보고 학습하면서, 직접 고민해보는 시간이 부족했다고 생각했다. public class Delivery { private Order order; public boolean validateOrder(Order order) { if (validateItemSize(order)) { log.info("주문 항목이 없습니다."); return false; } if (validateTotalPrice(order)) { log.info("올바르지 않은 총 가격입니다."); return false; } if (DoesNotHaveCustomerInfo(order)) { log.info("사용자 정보가 없습니다."); return false; } return true; } private boolean validateTotalPrice(Order order) { return order.getTotalPrice() 1주차 회고 계획한 것 보다 강의와 미션에 시간을 할애하지 못했다.과제를 제출하고, 다른 참여생분들이 작성한 미션을 보면서 반성하고 자극되었다.특히 아쉬운 점은, 과제를 pdf, github 등을 통해 더 깔끔하게 제출할 수 있었는데 하지 못한점이 아쉽다.좋았던 점은, 워밍업 클럽이라는 곳에 소속감이 생겨서 주어진 기간내에 강의를 완강했다는 것. 혼자 수강했다면 이 정도 진로를 나갈 수 없었을 것이라고 생각한다.가장 좋았던 것은 미션이었다. 강의에서도 가장 좋은 점이 직접 리팩토링을 하는 시간이 많다는 것.워밍업 클럽에서도 미션이 가장 좋았다. 직접 무언가를 하는 경험이 지금의 내게 가장 맞다고 생각되었다.