워밍업 클럽 3기 BE 클린코드&테스트 - 4주차 발자국

📖 강의 요약Dummy : 아무것도 하지 않는 깡통 객체Fake : 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체Stub : 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체. 그 외에는 응답하지 않는다.Spy : Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체, 일부는 실제 객체 처럼 동작 시키고 일부만 Stubbing할수 있다. (상태 검증)Mock : 행위에 대한 기대를 명세하고, 그 에 따라 동작하도록 만들어진 객체 (행위 검증)Spring REST Docs테스트 코드를 통한 API 문서 자동화 도구API 명세를 문서로 만들고 외부에 제공함으로써 협업을 원활하게 한다.기본적으로 AscliDoc을 사용하여 문서를 작성한다.장점테스트를 통과해야 문서가 만들어 진다.프로덕션 코드에 비침투적이다단점코드양이 많다설정이 어렵다💡 미션 1. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.2. 아래 3개의 테스트가 있습니다. 내용을 살펴보고, 각 항목을 @BeforeEach, given절, when절에 배치한다면 어떻게 배치하고 싶으신가요?(@BeforeEach에 올라간 내용은 공통 항목으로 합칠 수 있습니다. ex. 1-1과 2-1을 하나로 합쳐서 @BeforeEach에 배치)미션 제출 url : https://inf.run/7N27s 💬 회고 인프런 워밍업 클럽 스터디가 종료 하였다 1달동안 클린코드와 테스트 코드 강의를 들으며 코드에 대해서 생각해보는 좋은 기회 였다.📎출처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

워밍업 클럽 3기 BE 클린코드&테스트 - 3주차 발자국

📖 강의 요약통합 테스트여러 모듈이 협력하는 기능을 통합적으로 검증하는 테스트일반적으로 작은 범위의 단위 테스트만으로는 기능 전체의 신뢰성을 보장 할 수 없다,풍부한 단위테스트 & 큰 기능 단위를 검증하는 통합 테스트 ORM객체 지향 패러다임과 관계형 DB 패러다임의 불일치ORM을 사용함으로써 개발자는 단순 작업을 줄이고, 비즈니스 로직에 집중할 수 있다. Persistence LayerData Access의 역할비즈니스 가공 로직이 포함 되어서는 안된다. Data에 대한 CRUD에만 집중한 레이어 Business Layer비즈니스 로직을 구현하는 역할Persistence Layer와의 상호 작용 (Data를 읽고 쓰는 행위)을 통해 비즈니스 로직을 전개 시킨다.트랜잭션을 보장해야 한다. Presentation Layer외부 세게의 요청을 가장 먼저 받는 계층파라미터에 대한 최소한의 검증 !! CQRS (Command and Query Responsibility Segregation)데이터 저장소로 부터 읽기와 업데이트 작업을 분리하는 패턴= Command와 Query 를 분리 하기💡 미션 [Readable Code] 강의의 두 프로젝트(지뢰찾기, 스터디카페) 중 하나를 골라, 단위 테스트를 작성해 봅시다.미션 제출 url : https://github.com/2unmini/readable-code/tree/mission/day11 최대한 테스트 코드를 작성할때 현재 코드를 건드리지 않고 짤려고 했다 하지만 final Scanner 부분에서 문제가 발생했다 . 현재 코드는 각각의 테스트는돌아가지만 전체 테스트를 할때는 통과하지 못하지만 Scanner를 상수로 두지 않고 기존 코드를 변경한다면 테스트 코드도 성공적으로 잘 돌아갈 것이다. 💬 회고 👍 테스트에 관한 옛날에 대한 나의 생각나에게 테스트는 란 1+1 =2 처럼 이미 결과가 도출 되어있는 상황인데 테스트 코드를 작성 할 필요가 있을 까? 라는 의문 투성이 밖에 없었다. 정답은 아닐지는 모르지만 강의와 스터디를 통해 왜 테스트 코드를 작성해야 하는가를 어느 정도 이해를 하게 되는 것 같았다. 나만 1+1 =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

워밍업 클럽 3기 BE 클린코드&테스트 - 2주차 발자국

📖 강의 요약 1⃣ 코드 다듬기 주석의 양면성"좋은 주석"우리가 가진 모든 표현 방법을 총 동원해 코드에 의도를 녹여 내고, 그럼에도 불구하고 전달해야 할 정보 가 남았을 때 사용(메서드,변수,클래스) 네이밍에서 의도가 드러나면 주석을 대신 할 수 있을 것 같다. 변수와 메서드의 나열 순서- 변수는 사용하는 순서대로 나열 - 공개 메서드 끼리 기준을 가지고 배치하는 것이 좋음 - 또한 공개 메서드의 배치에 따라서 비공개 메서드의 순서도 고려 해야 한다. - 상태 변경 >> 판별 >= 조회 "결론"나열 순서로도 의도와 정보를 전달 할 수 있다는 것 패키지 나누기"결론"패키지는 문맥으로써 정보를 제공할 수 있다. 2⃣ 기억하면 좋은 조언들 복잡하거나 엉망인 코드를 이해하려 할때 리팩토링 하면서 읽기공백으로 단락 구분하기필요한 적정 수준보다 더 높은 수준의 엔지니어링이 아닌지 생각해보기 Practical Testing: 실용적인 테스트 가이드 1⃣ 테스트는 왜 필요할까커버할 수 없는 영역 발생, 경험과 감에 의존, 늦은 피드백, 유지보수 어려움"올바른 테스트 코드"자동화 테스트로 비교적 빠른 시간안에 버그를 발견할 수 있고, 수동 테스트에 드는 비용을 크게 절약할 수 있다.가까이서 보면 느리지만 멀리서 보면 빠르다. 2⃣ 단위 테스트 작은 코드 단위를 독립적으로 검증하는 테스트프레임 워크 : Junit / 라이브러리 : AsserJ테스트 코드를 작성 할 때는 해피 케이스만 하는 것이 아니라 예외케이스도 함께 작성 해야한다. 3⃣ TDD : Test Driven Development4⃣"TDD"프로덕션 코드 보다 테스트 코드를 먼저 작성해 테스트가 구현 과정을 주독하도록 하는 방법론 = 테스트 주도 개발선 테스트 - > 기능 구현 💡 미션 [섹션 7. 리팩토링 연습]의 "연습 프로젝트 소개" 강의를 보고, '스터디 카페 이용권 선택 시스템 프로젝트에서 지금까지 배운 내용을 기반으로 리팩토링을 진행해 봅시다' 미션 제출 url : https://github.com/2unmini/readable-code/tree/mission/day7 이번 미션에 대한 목표는 배운 내용+ 내가 알고 있는 내용을 가지고 생각해 봤을 때 이유가 충분 한지 판단하여 리팩토링을 해보았지만 다음 날 결과 비교를 해보았을 때는 많이 달랐지만 리팩토링 과제를 하는 동안 이유에 대해 많이 생각해보는 시간이였다. 💬 회고 👍 잘한 점인프런 가입 이후로 처음으로 강의 완료율 100% 달성일급 컬렉션을 적용하여 리팩토링 한점😮‍💨 아쉬웠거나 보완하고 싶은 점System.out.println()을 메소드를 추출할려고 생각했던 점이 아쉬웠다.배운 내용을 다 적용하지 않고 상황에 맞게 적용해 보고 싶다. 📎출처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

워밍업 클럽 3기 BE 클린코드&테스트 - 1주차 발자국

📖 강의 요약 2⃣ 추상우리가 클린 코드를 추구하는 이유"가독성"혼자만 사용한다면 아마 필요 없는 이야기 일수도 있을 것이다 하지만 개발자는 협업이 중요하다고 들었다.나만 코드를 읽는 것이 아니라 협업을 하는 사람들끼리 컨벤션도 중요하지만 그 전에 가독성 있는 코드를 짜면 원활한 작업을 할수 있을 것이라고 생각한다. 추후 발생하는 비용들도 줄어들 것이다.이번 섹션에서 강조하는 것은 제목처럼 추상인 것 같다.추상을 알아보자"추상"중요한 정보는 가려내어 남기고 덜 중요한 정보는 생략하여 버린다.미션에서 제출한 내가 이해한 추상과 구체를 위와 같이 예시를 들수 있을 것 같다.[추상] 인프런 워밍업 클럽 3기 BE 클린코드 & 테스트를 수료 한다. [구체] 2 개 강의(Readable Code: 읽기 좋은 코드를 작성하는 사고법&Practical Testing: 실용적인 테스트 가이드 )를 100 % 수강한다. 주 1회(총 4회) 발자국 작성을 한다. OT를 포함한 총 3회 온라인 라이브를 출석한다 미션 6개 중 5개 이상 기한 내 제출 완료한다.추상화의 가장 대표적인 행위는 이름 짓기,메서드 선언, 동등한 추상화 레벨, 매직 넘버,매직 스트링 제거 등 이 있다.위 주제에서 공통적으로 이름을 잘 짓는 것이 기반이 되는 것 같다. ex) 변수이름, 메서드 이름, 상수 이름 3⃣ 논리, 사고의 흐름이번 섹션에서 한마디로 정리하자면 빼고 생각하자 였다. (로직이 복잡하면 그 내가 먼저 생각 할 수 있는 상황부터 먼저 거르고 생각하기)추가적으로 부정어, 예외처리, null,optional에 대해 한번 더 생각해보고 작성해보기 4⃣ 객체 지향 패러다임이번 섹션은 좀 반성을 좀 하였다. 특히 강의 중 getter 사용 에 대한 이야기 였는데 무조건 getter를 사용하면 객체안에 정보를 가져올수 있잖아라고 생각하는 나에게 생각을 많이하게 되었다.핵심 : 관심사를 분리, 높은 응집도, 낮은 결합도, getter를 사용하기 전에 객체의 메시지를 보내서 그 값을 사용할수 있는 지 부터 생각하는 능력 기르기 SOLID 원칙✅SRP : 하나의 클래스는 단 한 가지 변경 이유(= 책임) 만을 가져야 한다.✅OCP: 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.✅LSP: 자식 클래스는 부모클래스의 책임을 준수하며, 부모 클래스의 행동을 변경하지 않아야 한다.✅ISP : 클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안된다.✅DIP : 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다. 5⃣ 객체 지향 적용하기이번 섹션은 내가 잘 이해를 잘못한 것 같아 다시 보아야 할 것 같다. 지금은 일기 정도로 작성 하지만 이해하여 꼭 적어보자강의를 듣고 옛날에 내가 작성한 코드(전체 코드 x)가 생각 났다.public enum ReservationStatus { PENDING("PENDING") { @Override public boolean canChangeTo(ReservationStatus status) { switch (status) { case APPROVED, CANCELED, EXPIRED -> { return true; } } return false; } }, APPROVED("APPROVED") { @Override public boolean canChangeTo(ReservationStatus status) { return status.equals(APPROVED); } }, CANCELED("CANCELED") { @Override public boolean canChangeTo(ReservationStatus status) { return status.equals(CANCELED); } }, EXPIRED("EXPIRED") { @Override public boolean canChangeTo(ReservationStatus status) { return status.equals(EXPIRED); } };지금 보니 메서드 명도 바꿀 필요가 있고 switch 사용으로 유지보수 어려움, if-else 사용 등 고쳐야할 부분이 많은 것 같다.목표 : 강의를 어느 정도 이해하여 코드를 바꿔보기 💡 미션 코드와 설명을 보고, [섹션 3. 논리 의 사고 흐름]에서 이야기 하는 내용을 중심으로 읽기좋은 코드로 리팩토링 해보기 블로그: https://zunmin4030.tistory.com/56 먼저 사이즈가 0이면 어떤 행위를 하고 0보다 크면 어떤 행위 0보다 작으면 어떤 행위를 한다라는 접근으로 코드를 이해 하는 것 부터 시작하였다. 거기에 대한 궁금증을 가지고 섹션별 내가 적용할 수 있는 부분을 생각해보았다. 이름짓기 , 부정 연산자 제거, Early return을 생각하여 과제를 해결하다보니 처음 코드를 말로 정리했을 때 생긴 궁금증을 해소 할수 있었다. 💬 회고 👍 잘한 점배운 것을 하나씩 적용해 보며 과제를 수행 해 나갔다.😮‍💨 아쉬웠거나 보완하고 싶은 점섹션 5에 대한 이해를 하지 못해 한번 더 공부 해야겠다. 📎출처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