워밍업 클럽 4기 - 백엔드 4주차 발자국

1. 학습 내용 각 계층별(persistence, business, presentation)로 테스트 코드 짜는 방법 중 presentation Layer 테스트에 대해서 마무리 학습을 할 수 있었다. 현재 회사에서는 REST Assured을 이용해 테스트 코드를 작성 중이었는데 @WebMVC을 이용한 방법을 학습할 수 있었다. 해당 방법을 알려주시면서 mockito에 대한 설명도 해주셔서 테스트 기술을 사용하는 흐름에 대해서 이해하기 좋았다. presentation Layer 테스트에 대한 학습을 마무리 후 Day 16 미션으로 레이어별로 특성과 테스트 방법을 정리하면 6세션에 대한 복습을 할 기회를 얻을 수 있었다. 7세션에서는 Mock에 대해서 학습하였다. presentation Layer에서 간단하게 설명해 주셨던 부분에 대해서 좀 더 자세히 알 수 있었다. Test Double의 5가지에 대해서 설명해 주셨고, 이를 실제 코드에서 적용하면서 이해할 수 있었다. 이어서 Day 18미션 역시 해당 세션에 대해서 복습할 수 있는 미션을 통해 학습한 내용에 대해서 정리해 볼 수 있었다. 8세션에서는 테스트 코드들에 대한 조언들에 대해서 설명 주셔서 테스트 코드를 작성할 때 고려할 점들에 대해서 생각해 볼 수 있었다. 9 세션은 부록으로 테스트 코드를 통해 학습하는 방법과 Spring REST Docs 사용법에 대해서 알려주셨다. 2. 느낀 점테스트 코드의 중요성에 대해서 한번 더 느끼게 되었고, 테스트 코드를 작성할 때도 코드를 작성할 때만큼 많은 고민이 필요함을 느끼게 되었다. 테스트 코드 역시 문서고, 레거시가 되기 때문에 테스트 코드에서 역시 가독성을 고려하기 위한 리팩토링 작업을 꾸준히 해야 겠다는 생각이 들었다. 그리고 테스트 작성을 위한 내가 모르는 도구들과 방법론이 무궁무진하다는 것을 알았다. 이 부분 역시 꾸준히 공부해 나가야 할 부분인 듯하다..*수강 강의:Practical Testing: 실용적인 테스트 가이드 - 박우빈

워밍업 클럽 4기 - 백엔드 Day 18 미션

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.@MockMockito원하는 반환값만 설정할 수 있는 가짜 객체를 생성.단위 테스트에서 Spring 없이 빠르게 테스트할 때 유용.@MockbeanSpring ApplicationContext에 등록된 실제 빈을 Mock 객체로 교체Spring 환경에서만 사용 가능. @Spy실제 객체를 그대로 생성한 뒤, 그 객체의 일부 메서드만 선택적으로 바꿔서 사용.특정 메서드의 결과를 지정할 수 있음. @Spybean실제 빈을 감싸서 사용할 수 있게 해줌 -> 진짜 로직을 사용하면서 특정 메서드만 mocking 가능. @InjectMocks@Mock 또는 @Spy로 선언된 객체들을 자동으로 주입 -> 의존성 주입이 필요할 때 도와줌Spring이 없는 테스트 환경에서 테스트 대상 객체구성을 도와줌 2. 아래 3개의 테스트가 있습니다. 내용을 살펴보고, 각 항목을 @BeforeEach, given절, when절에 배치한다면 어떻게 배치하고 싶으신가요?@BeforeEach void setUp() { 사용자 생성에 필요한 내용 준비 사용자 생성 게시물 생성에 필요한 내용 준비 게시물 생성 } @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 미션

Layered Architecture는 3 tier(4tier)라고도 하며, 계층적으로 레이어(Persistence Layer, Business Layer, Presentation Layer)를 나누어 책임을 구분하는 방식이다.하지만 규모가 커질수록 하위 계층에 강하게 결합될 수 있어 헥사고날 아키텍처가 사용된다.Persistence Layer특징:데이터베이스에 직접 접근하는 계층이며, 주로 Mapper, repository등이 담당한다. 비즈니스 로직이 들어가면 안되고 오직 crud같은 디비 작업을 위한 작업만 수행해야 한다. 테스트 방법:-서비스 DB 환경이랑 테스트 DB 환경이 다를 경우 프로파일 분리를 해서 테스트 환경을 서비스와 다르게 구성해서 사용할 수 있다.(@ActiveProfiles 사용 필요) -@SpringBootTest vs @DataJpaTestDataJpaTest가 jpa 관련 빈들만 주입해 주기 때문에 더 가볍다. Business Layer특징:핵심 비지니스 로직을 구현하는 계층으로,Persistence Layer과 상호작용하며, 여러 Repository 들이 조합되기 때문에 롤백에 대한 문제가 발생할 수 있다. 따라서 이를 위해 트랜잭션 관리를 잘 해주어야 한다.테스트 방법:-단위 형태로 작성하되, 각각의 테스트가 분리될 수 있는 조치를 해야 한다. (TearDown Method 구현을 구현하여 @AfterEach로 각 테스트 종료시 생성된 데이터들을 지워주어야 한다.)-@SpringBootTest vs @DataJpaTest:@DataJpaTest는 자동 롤백이 된다. Presentation Layer특징:외부 세계 요청을 가장먼저 받는 계층으로 프론트엔드에서 넘겨준 값을 먼저 받거나, 최종 가공 데이터를 전달해 주는 계층,비즈니스 로직을 들어가면 안되고 데이터에 대한 검증이 필요한 계층이다. 테스트 방법:-@WebMvcTest + MockMvc를 이용한 테스트-실제 요청/응답 흐름을 시뮬레이션-Controller 단에서 validation, 응답 포맷 등을 검증 강의 출처 Practical Testing: 실용적인 테스트 가이드

워밍업 클럽 4기 - 백엔드 3주차 발자국

1. 학습 내용이번주는 레이어드 별 테스트 만드는 법에 대하여 학습했다. 지난 시간에 말씀하신 것처럼 TDD로 만들면서 각 테스트 코드 만드는 법에 대해서 만들었다. 각 계층별(persistence, business, presentation)로 테스트 코드 짜는 방법에 대해서 설명해 주셨다. 2. 느낀 점항상 테스트 코드 작성에 부담을 느끼고 있었지만, TDD로 개발하면서 코드를 수정해 나가니 테스트 코드는 기본적으로 작성될 수 있었다. 보통은 비즈니스 로직 정도만 테스트 코드를 작성했는데 계층별로 테스트 코드를 꼼꼼히 작성해 나가야 함을 깨닫게 되었다. JUnit과 AssertJ를 사용한 테스트 코드 이외에도 직접 코드 작성을 해보면서 여러 팁을 주셔서 좋았다. (@DataJpaTest와 @SpringBootTest 차이점 같은 기술적 차이에 대한 설명 뿐만 아니라 동시성 이슈에 대한 고민이나 리팩토링 방식 등등 실무에서 만날 수 있는 문제들에 대해서 언급해 주셨다.) *수강 강의:Practical Testing: 실용적인 테스트 가이드 - 박우빈

워밍업 클럽 4기 - 백엔드 2주차 발자국

1. 학습 내용지난 강의에 이어서 6세션에서는 코드 다듬는 방법들에 대한 팁을 배웠고, 데이터 + 코드에서 코드 파트가 마무리 되었다.6세션이 끝나고 7세션의 코드 다듬기 강의를 시청하기 전에 미리 리팩토링 연습을 하는 미션이 주어졌다.스스로가 먼저 적용해 보고 비교하며 리팩토링 강의를 듣고 이외에 8세션을 들으며 책 추천과 관련 조언들을 얻을 수 있었다. Practical Testing 강의에 들어갔다.테스트 코드 역시 실무에서 필요성은 느끼지만 적용해 보는 것에 부담을 느끼는 편이었는데 세션 2를 통해 한번 더 필요성을 인식하게 되었다. 중간점검에서는 Q&A와 미션에 대한 리뷰로 진행되었다. 2. 느낀 점아직 추상화에 대한 어려움이 있는데 이는 강의에서 말씀하신 것처럼 많이 해봐야 감이 좀 잡힐 것 같다는 생각이 들었다. 미션으로 리팩토링 작업을 해보고 비교해 보는 시간을 가지니 놓친 부분을 많았다. 가독성 좋은 코드를 얻기 위해서는 많은 연습과 노력이 필요할 것 같다. 그리고 팀내에서 테스트 코드를 작성하면서 항상 나왔던 말은 "테스트를 위한 테스트 코드는 만들지 말자" 였는데 실제로 테스트 코드를 만들다 보면 이런 약속이 잘 지켜지지 않았다. 강의에서는 테스트 코드를 짜는 것 뿐만 아니라 잘 짜는 것이 중요하다고 말씀하셨는데 강의를 듣고 좋은 테스트 코드를 만들기 위한 노력도 시도해 봐야 겠다는 생각이 들었다. *수강 강의:Readable Code: 읽기 좋은 코드를 작성하는 사고법 - 박우빈Practical Testing: 실용적인 테스트 가이드 - 박우빈

워밍업 클럽 4기 - 백엔드 1주차 발자국

1. 학습 내용실제로 실무에서 코드를 작성하는 경우보다 기존에 작성된 코드를 읽어야 하는 경우가 많고,그렇기에 내 코드를 읽게 될 동료들 뿐 아니라 미래의 나를 위해 가독성 좋은 코드를 작성해야 하는 것은 필수적이다.한번에 가독성 좋은 코드를 만드는 것은 어렵기에 끊임없는 리팩토링 작업이 필요한데 Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의는 실제 예시를 통해 리팩토링 할 수 있는 방법을 알려 주었다.강의에서는 프로그램을 데이터 + 코드로 나눈다. 2 세션에서 데이터를 가독성 좋게 하기 위한 방법으로 추상을 알려 주고 이를 통해 네이밍에 어떻게 주요 정보를 넣을지에 대해서 다뤘다. 그리고 Day2미션을 통해 실제 우리 주변에서 사용되고 있는 추상-구체에 대해서 생각해 볼 계기를 가질 수 있었다. 2세션 이후는 모두 코드를 가독성 좋게 하기 위한 방법으로 이번 주차에서는 5세션까지 수강하였다. 3세션에서는 뇌의 경제성을 위한 방법론들을 제시해 주셨다. 그리고 배운 내용을 바탕으로 Day4 미션에서 연습해 볼 수 있었다. 4, 5세션에서는 객체지향적으로 코드를 작성할 수 있는 방법을 배울 수 있었다. 2. 느낀 점실제로 이름 짓기에 어려움이 컸는데 작문과 비교해 주신 부분이 좋았다. 내가 작성한 문단(코드 덩어리)에서 핵심 내용은 무엇인지 고민해 보게 되었고, 이론으로만 알고 있던 실제 코드에서 어떻게 녹아내야 하는지 잘 잡히지 않던 SOLID에 대해서 코드 리팩토링 과정을 통해 볼 수 있어서 좋았다.많은 내용을 얻은 만큼 복습 과정과 실제로 내가 기존에 작성해온 코드에 적용해 봐야 겠다. *수강 강의:Readable Code: 읽기 좋은 코드를 작성하는 사고법 - 박우빈(https://www.inflearn.com/course/readable-code-%EC%9D%BD%EA%B8%B0%EC%A2%8B%EC%9D%80%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%EC%82%AC%EA%B3%A0%EB%B2%95/dashboard)

워밍업 클럽 4기 - 백엔드 Day 4 미션

1. 아래 코드와 설명을 보고, [섹션 3. 논리, 사고의 흐름]에서 이야기하는 내용을 중심으로 읽기 좋은 코드로 리팩토링해 봅시다.import java.util.List; import java.util.logging.Logger; class Order { private final List items; private final Customer customer; public Order(List items, Customer customer) { this.items = items; this.customer = customer; } public boolean hasNoItem() { return items == null || items.isEmpty(); } public boolean isTotalPriceInvalid() { return calculateTotalPrice() 참고: Readable Code: 읽기 좋은 코드를 작성하는 사고법 세션 3 2. SOLID에 대하여 자기만의 언어로 정리해 봅시다.SRP (단일책임 원칙)single responsibility principle하나의 클래스는 하나의 책임(관심사)만 갖는다.메서드에서 하나의 역할을 가져야 하는 것과 유사한 개념한 클래스의 책임이 두가지 이상이라면 유지보수하기가 어렵다. -> 변경 가능성이 높아진다! OCP (개방폐쇠 원칙)open-closed principle확장(다형성)에는 열려 있고, 수정(코드 변경)에는 닫혀 있다.기존 코드의 변화가 많지 않게 시스템을 확장할 수 있어야 한다! LSP (리스코프 치환 원칙)Liskov substitution principle부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환할 수 있어야 한다. 자식 클래스는 부모 클래스의 책임을 준수해야 한다! 부모의 기능을 모두 갖춘 채 확장해야 한다! ISP(인터페이스 분리 원칙)interface substitution principle인터페이스의 기능 단위로 쪼개야 한다. 인터페이스 안에 내가 사용하지 않는 기능이 들어 있으면 안된다. DIP(의존성 역전 원칙)dependency inversion principle상위 수준의 모듈이 하위 수준의 모듈에 의존해서는 안 된다.추상화 레벨이 높은 쪽에서 추상화 레벨이 낮은 쪽(구체화)에 의존하면 안된다!의존성: 하나의 모듈이 다른 하나의 모듈을 알고 있거나 직접적으로 생성하거나 사용하는 것

워밍업 클럽 4기 - 백엔드 Day 2 추상과 구체 미션

추상“언제 밥 한번 먹자” 구체– 관계를 완전히 끊지는 않겠다는 제스처.– 지금은 어색하거나 바쁘지만, 언젠가는 마음을 열고 싶다는 희망 혹은 체면.– 때로는 진심이지만, 자주 현실로 이어지지 않는 인사말.