워밍업 클럽 4기 BE 클린코드 4주차 발자국

4주차를 마무리하며...워밍업 클럽의 마지막 주에는 테스트 강의를 마무리하는 시간이 였습니다. 그리고 마지막 점검을 통해 제가 놓치고 있는 테스트의 시야를 넓혀주는 시간을 보냈습니다. ^^✅ 하나의 테스트에는 하나의 목적의 검증만!테스트 코드는 문서의 역할을 하기도 합니다.이를 글쓰기 관점에서 보았을때, 한문단에 하나의 주제만 쓰는것이 전달하기에 명료한 것과 같이 볼 수 있습니다.반복문과 분기문(논리구조)은 되도록 안 쓰는 테스트가 좋습니다.✅ 테스트에 대한 환경은 완벽하게 제어제어 가능한 영역과 불가능한 영역을 구분하여 테스트 코드를 작성하는 것이 좋습니다.외부 시스템 같은 경우 mock객체를 사용합니다.✅ 테스트 환경의 독립성을 보장하나의 테스트에서는 하나의 행위에 대한 내용으로 작성하는 것이 좋습니다.두가지의 행위가 혼합되어진 테스트인 경우에는 읽는이가 논리적으로 한번 더 생각해야 하고, 주 목적에 맞지 않는 이유로 테스트의 목적을 보장할 수 없게됩니다.✅ 테스트 간 독립성을 보장테스트 코드간은 서로 독립되어 동작해야 합니다.테스트 간에 순서가 생기면 안됩니다.공유 변수나 영향을 주는 persistence는 제거!사용해야하는 상황에서는 dynamic test 사용합시다.✅ Test Fixture 구성Fixture: 고정물, 고정되어 있는 물체, 테스트를 위해 원하는 상태로 고정시킨 일련의 객체(주로 given절에서 사용)@BeforeAll, @BeforeEach, @AfterEach를 통해 매 테스트에 사용할 객체를 고정시키는 것은 각 테스트의 독립성에 저해됩니다.무분별한 setup은 정보의 파편화로 인해 가독성에 저해됩니다.@BeforeAll, @BeforeEach, @AfterEach를 사용할 때는 다음과 같은 내용을 확인합시다.각 테스트를 이해하는데 아예 몰라도 되는 내용인가?수정해도 모든 테스트에 영향을 주지 않는가? ✅ Test Fixture 클렌징@AfterEach에 persistence layer의 repository의 delete메서드 실행합니다.@Transactional 사용하면 자동으로 rollback을 해줍니다만, 비즈니스 레이어에 트랜잭션에 대한 부분을 확인하기 어렵다는 사이드 이펙트가 있습니다.✅ @ParameterizedTest여러가지 파라미터(데이터)에 대해서 테스트를 진행하고 싶을 때 사용합니다.https://inf.run/7Vw48✅ @DynamicTest시나리오 테스트를 할 때 유용하게 사용할 수 있습니다.단계별로 행위와 결과를 검증합니다.https://inf.run/9nLpf✅ 테스트 수행도 비용이다각 테스트의 환경을 통일하여 테스트에 드는 비용을 줄일 수 있습니다.추상클래스를 상속받아서 테스트 코드가 돌아가도록 하면 환경을 통합해서 시간을 아낄 수 있습니다.상위클래스에 테스트에 필요한 빈들을 한번에 주입받아 여러번 spring 플레임 워크가 초기화하는 횟수를 줄일 수 있습니다. ✅ Private Method Testprivate method test는 할 필요가 없습니다.private method를 테스트 해야할 시점은 객체를 분리할 시점으로 볼 수 있습니다.✅ 테스트에서만 필요한 코드?생성자나 빌더와 같이 테스트에서만 사용되는 코드는 최소한으로 허용합니다.미래시점에 객체에 가져도되는 행위라고 생각이 되는경우 부담없이 사용합니다.✅ 시간. 시간. 시간시간이라는 요소는 개발자에게 선택을 강요합니다.한정된 시간에서 올바른 테스트를 작성하기 위해서는 테스트를 추론하고, tdd가 익숙해질 때까지 반복이 필요합니다. 요구사항에 매몰되기 보다는, 어떤 케이스로 코드를 검증할 수 있을지 한번 생각해보는 훈련이 필요합니다.도구를 빠르게 효율적으로 적재적소에 활용하기 위해서는 많이 사용해봐야 합니다.마지막 중간 점검그간 진행해오던 과제에 대해서 내가 제일 신경 쓴 부분은 중복제거, 깔끔해보이는 코드 였습니다. 이 생각이 잘못되었다는걸 이번 Day18 미션 리뷰에서 알 수 있었는데요. 중복제거나 깔끔해보이는 코드는 따라오는 효과이지, 그것이 목적이 되면 안될거라는 생각이 들었습니다. 리뷰에서 우빈님께서 하신 말씀 핵심은 중복 제거가 아니다. 도메인이다. 를 머리에 새겨넣어야겠습니다.워밍업 클럽 회고처음으로 여러명이 모여서 하나의 주제를 공부하는 시간을 보냈습니다. 짧다면 짧은 한달이지만, 응축되게 클린코드와 테스트 코드를 입문하기에 좋은 시간이 였습니다. 이 기간 동안 클린코드와 테스트 코드 짜는 저의 실력이 비약적으로 높아지지는 않았지만, 왜 필요하고 왜 꾸준히해야 하는지 목적의식을 심어주는 뜻깊은 시간이 되었습니다. 계속 이를 이어가고자.. 이 워밍업 클럽이 끝나고 따로 모여 스터디 진행을 신청했는데, 앞으로의 저의 생각과 코드에 많은 발전이 있기를 ...! 그동안 인프런 워밍업 클럽을 진행해주시느라 신경을 많이 써주신 박우빈 선생님과 인프런에 감사드리며 인프런 워밍업 클럽 "완"을 외치겠습니다!

인프런 워밍업 클럽 DAY 18 미션

1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.Mockito 어노테이션✔@Mock실제 객체가 아닌 가짜 객체를 생성하여 테스트에 사용합니다. 해당 객체는 아무런 동작을 하지 않으며, stub된 동작만 수행합니다.✔@Spy실제 객체를 감싸서 필요한 부분만 stub 처리할 수 있습니다.✔@InjectMocks테스트 대상 객체를 생성하고, 그 객체에 @Mock 또는 @Spy 객체를 자동으로 주입합니다.Spring Boot Test 어노테이션 ✔ @MockBean기존의 spring bean을 mock 객체로 대체합니다.✔ @SpyBean기존의 spring bean을 spy 객체로 대체합니다.2. 아래 3개의 테스트가 있습니다.내용을 살펴보고, 각 항목을 @BeforeEach, given절, when절에 배치한다면 어떻게 배치하고 싶으신가요?(@BeforeEach에 올라간 내용은 공통 항목으로 합칠 수 있습니다. ex. 1-1과 2-1을 하나로 합쳐서 @BeforeEach에 배치)@BeforeEach void setUp() { 1-1. 2-1. 3-1. 3-3. 사용자 생성에 필요한 내용 준비 1-3. 2-3. 3-5. 게시물 생성에 필요한 내용 준비 1-5. 2-5. 3-7 댓글 생성에 필요한 내용 준비 } @DisplayName("사용자가 댓글을 작성할 수 있다.") @Test void writeComment() { // given 1-2. 사용자 생성 1-4. 게시물 생성 // when 1-6. 댓글 생성 // then 검증 } @DisplayName("사용자가 댓글을 수정할 수 있다.") @Test void updateComment() { // given 2-2. 사용자 생성 2-4. 게시물 생성 2-6. 댓글 생성 // when 2-7. 댓글 수정 // then 검증 } @DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given 3-2. 사용자1 생성 3-4. 사용자2 생성 3-6. 사용자1의 게시물 생성 3-8. 사용자1의 댓글 생성 // when 3-9. 사용자2가 사용자1의 댓글 수정 시도 // then 검증 }공통되는 준비과정을 합쳐서 test fixture로 구성했습니다. (각 객체들의 생성 준비 과정)각 객체를 생성하는 코드도 겹치는 부분이 있으나, 각각의 단위 테스트를 이해하는데 있어서는 한 블럭 내에 있으면 좋겠다고 판단했습니다. 또한, 혹시 각 테스트에 객체를 구성할 때 필수 값들이 다를 수 있기때문에 set up에 위치하지 않았습니다.

인프런 워밍업클럽 백엔드 DAY 16 미션

Presentation Layer외부의 요청을 가장 먼저 받는 계층, 요청을 받아서 처리를 위임하고 값을 돌려주는 역할을 합니다.presentation layer 테스트실제 로직은 business + persistence 계층에서 수행되므로, presentation 계층에서는 값 검증과 반환 값을 위주로 테스트를 진행합니다.실제 서비스 로직은 모킹(Mock)하고, 요청을 보냈을 때 어떤 응답이 오는지를 확인합니다.Business Layer핵심 비즈니스 로직이 들어있는 부분입니다.작업의 원자성을 트랜잭션을 통해서 보장해야 합니다.business layer 테스트Persistence 계층과 통합으로 테스트를 진행합니다.로직이 요구사항에 부합하는지를 위주로 테스트를 합니다.예외값 경계값에 특히 신경씁니다.Persistence Layer데이터베이스와 직접 맞닿아있는 부분입니다.비즈니스 가공 로직이 포함되서는 안되며, CRUD 작업에만 집중해야 합니다.persistence 테스트실제 DB를 활용해 통합 테스트를 주로 사용합니다.쿼리가 의도대로 잘 작성되었는지 검증합니다.테스트에 생성된 데이터는 잊지말고 클렌징 해줍니다.

워밍업 클럽 3기 BE 클린코드 3주차 발자국

3주차를 마무리하며...테스트 코드에 대해서 공부하는 시간을 가졌습니다.실무에서도 red green refactoring을 습관화해서 사용하면 심리적으로 안정감 있는 직장 생활이 될 것 같다는 생각이 들었습니다.강의 내용정리테스트 코드테스트 코드(자동화 테스트)가 필요한 이유수동으로 테스트를 진행하면 시간이 비효율적으로 사용됩니다.인수인계가 어렵습니다.수동으로 테스트하기에는 휴먼오류에 대한 리스크가 존재합니다.테스트를 통해 얻고자 하는 것빠른 피드백과 자동화 그리고 안정감을 얻을 수 있습니다.단위 테스트작은 코드 단위를 독립적으로 검증하는 테스트를 단위테스트라고 합니다.외부에 의존하지 않고 검증을 하도록 설계하여 속도가 빠르고 안정적입니다. 단위 테스트 작성할 때 주의점암묵적이거 아직 드러나지 않은 요구사항이 있는가? 에 대한 의문을 가지며 테스트 케이스를 세분화 하여야 합니다.해피케이스, 예외케이스에 대해서 고루 케이스를 세분화하여야 합니다.테스트하기 어려운 값 (외부 값, 시간)에 대해서는 분리하여 테스트에 용이한 구조로 만드는 것이 좋습니다. Layered Architecture와 테스트Persistence Layer Test쿼리가 의도대로 잘 작성이 되었는지 확인합니다.쿼리를 구현하는 기술이 바뀌어도 기능의 동작을 보장하도록 테스트를 작성합니다.@DataJpaTest를 사용해 테스트를 진행하는 경우에는 Persistence Layer에 필요한 빈들만 주입받으며, 자동으로 테스트 후에 roll back을 해줍니다.Business Layer TestPersistence Layer와 상호작용을 통해 비즈니스 로직을 전개하며, 이를 테스트 합니다.요청값부터 만들어서 비즈니스 로직을 테스트 합니다.트랜잭션을 보장하는지 확인합니다.Presentation Layer Test주요 로직은 business+persistence의 트랜잭션 경계내에서 끝나므로, presentation 에서는 외부에서 들어오는 값 검증을 주로 수행합니다.의존 관계를 가짜객체를 사용해서 환경을 재현합니다.@WebMvcTest, @MockBean, MockMvc 객체 등을 사용합니다.미션 Day 11저는 스터디 카페를 프로그램에 테스트 코드를 추가 하였습니다. [깃 허브](https://github.com/lkwoung88/readable-code/commit/7be5050a1c76e78809d85258aadbddfc3a430f3a) 계산, 판정 로직에 대해서 테스튼는 큰 고민없이 작성하였지만, 파일에서 읽어오는 부분은 어떻게 테스트하면 좋을지 고민을 많이 하다가 결국에는 작성하지 못했습니다.

워밍업 클럽 3기 BE 클린코드 2주차 발자국

2주차를 마무리하며...2주 차에는 예제 코드의 리팩토링을 직접 해보는 과제와 중간 점검이 있었습니다.강의를 보며 따라 할 때는 괜찮았지만, 막상 코드에서 리팩토링을 하려니 무엇부터 시작해야 할지 막막하더군요.리팩토링은 강의만 본다고 해결되는 영역이 아니라는 것을 느꼈고, 체화되기까지 시간이 필요하겠다고 생각한 한 주였습니다.강의내용 정리좋은 주석이란?주석이 많다는 것은 코드에 적절한 추상화를 적용하지 못해, 주석으로 코드를 설명하려는 것은 아닌지 의심해봐야 합니다.좋은 주석이란 코드로 전달할 수 없는 정보를 담는 것입니다.예를 들어, 의사 결정의 히스토리 같은 내용을 기록하는 것이 좋은 주석입니다.또한, 주석도 코드와 마찬가지로 버전 관리가 필요합니다. 관련된 의사 결정이 변경되었다면, 주석도 잊지 말고 함께 수정해야 합니다. 변수와 메서드 나열변수는 사용하는 위치와 최대한 가까이 두어 뇌 메모리 부담을 줄이는 것이 좋습니다.메서드와 변수의 접근자 종류에 따라 위치를 정리할 수 있습니다.메서드는 접근자 종류뿐만 아니라, 중요도와 로직의 종류를 기준으로 배치하면 더 정리된 코드를 만들 수 있습니다. 패키지 나누기패키지는 단순한 디렉터리가 아니라, 문맥적인 정보를 제공하는 역할을 합니다.적절하게 패키지를 나누면 코드의 가독성과 유지보수성이 향상됩니다. IDE 활용하기정렬 단축키를 활용하여 코드 스타일을 통일합니다.Linting & 스타일 도구를 사용하여 코드 품질을 높일 수 있습니다.SonarLintEditorConfig리팩토링 직접 해보기리팩토링리팩토링에는 합리적인 이유가 필요하다리팩토링을 할 때는 단순히 코드 줄 수를 줄이는 것이 목표가 아니라, 객체의 역할과 책임을 올바르게 분배하고, 적절한 추상화를 적용하는지가 중요합니다. 이를 위해 리팩토링 과정에서 내가 합리적으로 수정하고 있는지 계속 의심하며 진행했습니다. (제가 정말 합리적으로 했는지는 모르겠습니다만...) 리팩토링 순서 정하기처음 코드를 봤을 때, 어디서부터 손을 대야 할지 막막함을 느꼈습니다. 그래서 나름의 리팩토링 순서를 정하고 진행해보았습니다.내가 읽기 좋은 코드로 변경하기공백 추가하기 (가독성 개선)함수 분리하여 추상화하기테스트하기 쉬운 구조로 변경하기역할과 책임을 고려하여 인터페이스와 객체로 분리하기 가독성 개선하기패키지 분리하기 리팩토링에는 정답이 없다리팩토링은 정해진 답이 없다는 점이 가장 어렵게 느껴지는 부분인 것 같습니다. 중간점검Day 4 미션 피드백아래는 제가 미션으로 제출한 코드입니다.이번 점검에 피드백으로 얻은 새로운 인사이트를 나열해봅니다.반환 타입이 boolean인 경우, 예외를 발생시키기 전에 해당 메서드의 사용 현황을 먼저 파악한 후, 상황에 맞게 리팩토링해야 한다.예외를 던지는 것은 비용이 많이 들 수 있으므로, 필요할 때만 신중하게 사용해야 한다. private static boolean VALID = true; public boolean validateOrder(Order order) { if (order.isItemEmpty()) { throw new AppException("주문 항목이 없습니다."); } if (order.isTotalPriceLessThenZero()){ throw new AppException("올바르지 않은 총 가격입니다."); } if (order.hasNotCustomerInfo()) { throw new AppException("사용자 정보가 없습니다."); } return VALID; }Day 7 미션 피드백물론 리뷰를 할 때, 말을 조심스럽게 해야할 테지만, 코드 리뷰의 목적은 다 같이 좋은 코드를 만들어 보자는 좋은 의미입니다.코드 리뷰를 할 때는 인격적인 모독을 하지 않는다.코드 리뷰를 받을 때는 코드와 나를 동일시 하지 않는다.배운 점 정리 정적 메서드 팩토리를 만들 때는 생성자를 private으로 감춘다.null 대신 Empty 객체를 만들어서 처리한다.단수/복수를 신경 써서 변수명과 메서드명을 짓는다.리팩토링에는 정답이 없다. 하지만, 효율적인 구조와 다양한 의견이 있다.

워밍업 클럼 3기 BE 클린코드 1주차 발자국

1주차를 마무리하며...업무와 같이 할 수 있겠지 싶었는데, 강의의 내용이 알차서 생각보다 힘들었습니다.코드를 따라치며 수강했지만... 사실 제대로 이해 못하고 따라만 친 부분도 상당히 있었는데,다시 내가 직접 리펙터링 해가며 따라가야지 다짐을 하며 1주차 발자국을 남깁니다.강의 정리클린코드란 무엇인가라는 질문으로부터 강의가 시작됩니다.좋은 코드란 무엇일까요?저는 강의의 내용을 듣고 이렇게 정리했습니다.좋은 글과 마찬가지로 클린코드는 잘 읽히는 코드한 문장 한 문장에 주제가 또렷해 전달하고자 하는 내용을 읽는 이에게 정확하게 전달하는 코드강의에서 중간중간에 선조와 후손이라는 용어를 사용하십니다. 내가 쓰는 코드가 꼭 내것만은 아니라는 점을 계속 상기시켜주시면서, 공용의 코드를 어떻게 다뤄야할지는 말씀해주시는게 많이 도움이 될 것 같습니다.추상화추상이란 '사물을 정확하게 이해하기 위해서 사물이 지니고 있는 여러 가지 측면 가운데서 특정한 측면만 가려내어 포착하는 것'을 말합니다.'비가온다' 라는 표현을 '대기내에 수증기가 응결하여 물방울로 변하고, 이 물방울이 중력에 의해서 지표면으로 떨어진다'라고 친구한테 말하면 갸우뚱할 것입니다.이처럼 추상은 중요한 정보만 남겨 전달함으로써 상대방의 이해를 돕는 기능을 하는걸 실생활에서도 볼 수 있습니다.코드에서의 추상화그러면 코드에서는 어떻게 중요한 내용만 가려내고, 구체적인 내용은 숨겨 읽는 이의 이해를 도울 수 있을까요?강의에서 나온 내용들 중 기억에 남는 방법들을 나열해봅니다.코드 블럭내에서 추상화 레벨을 통일하기객체에 적절한 역할과 책임을 부여하고 메시지를 통한 협력을 하는 구조로 만들기SOLID 원칙을 생각해가며 코드를 작성하기객체지향의 다양한 기법을 활용하기상속과 조합Value Object컬렉션으로 포장한 일급컬렉션 사용하기Enum다형성 그리고 읽는 사람을 배려한 다양한 코드 작성법을 나열해봅니다.변수, 메서드 추상화를 통해 이름 짓기매직 넘버, 매직 스트링 상수화하기공백 라인 활용해 블럭내 코드 분간해주기조건문에 부정어 연산자 `!`줄이기