블로그

조혜림

[인프런 워밍업 클럽 스터디 2기] 프로덕트 디자인 3주차 발자국

이번 주에는 네비게이션 제작과 다크모드 및 브랜드, 반응형 베리어블 모드의 개념을 이해하고 해당 데이터를 베리어블로 등록을 진행하였다. 또한 3주간 배운 내용을 토대로 쇼핑몰 관리자 페이지와 로그인 페이지를 제작하였다. 금주에 배운 강의 내용은 다음과 같다. 네비게이션 컴포넌트 제작링크, 브레드크럼 제작네비게이션 탭과 모바일 하단 네비게이션 제작페이지 네이션 제작헤더 제작사이드 네비게이션 제작이미지캐러셀 제작홈페이지에서 필수적으로 배치되는 다양한 네비게이션을 제작하고 이 네비게이션을 반응형에 맞추어 수정을 진행하였다. 네비게이션의 경우 디바이스 레이아웃에 영향을 많이 끼치는 컴포넌트이기 때문에 반응형에 대한 이해와 레이아웃 구조를 본격적으로 많이 고민하게 되었다. 처음에 반응형을 크게 고려하지 않고 제작했다가 다음 수업에서 가장 많이 수정 작업을 진행한 컴포넌트였다. 실무에서 활용할 때에는 네비게이션 제작할 때에부터 본격적으로 반응형 사이즈와 배치를 고려하여 네비게이션 레이아웃을 제작하여야겠다. 베리어블 개념 이해 및 실습다크모드 베리어블 개념 이해 및 활용브랜드 베리어블 개념 이해 및 실습반응형 베리어블 개념 이해 및 실습다중언어 지원 화면 구성1주차에 배웠던 베리어블에서 보다 심화하여 저장된 색상 베리어블을 다크모드와 브랜드로 구분하여 다양한 조합을 구성하는 방법을 배울 수 있는 시간이었다. 또한 반응형 베리어블을 구성함으로써 각각의 디바이스 별로 반응형 제작 시 필요한 다양한 수치를 변수화하여 디바이스에 맞는 데이터를 활용할 수 있는 방법을 배우고 실습하였다. 금주 수업 중 가장 많이 놀란 수업으로 베리어블을 구분하여 저장함으로써 클릭 몇 번으로 작업물의 다양한 테마를 변경하고 라이트/다크 모드로 변경할 수 있는 점이 정말 흥미로웠다. 다시금 피그마의 압도적인 생산성에 놀라고 실무에서 어떻게 활용하면 좋을 지 고민해보는 시간이 되었다. 조만간 타이포 베리어블도 업데이트 된다는 소식을 수업에서 들었는데 해당 업데이트로 얼마나 더 효율적일지 매우 기대가 된다. B2B 이커머스 어드민 페이지 만들기이커머스 어드민 페이지 제작다크모드 제작로그인 페이지 제작해당 수업부터는 지금까지 제작한 다양한 베리어블과 컴포넌트를 토대로 실제 페이지를 구성하고 제작하였다. 그간 제작한 베리어블이나 컴포넌트가 재료가 되어 필요한 지점에 유연하게 활용할 수 있어 매우 흥미로운 시간이었다. 또한 피그마를 활용하면 현재 내가 작업하는 환경에서 소모되는 시간보다 훨씬 적은 시간으로 다양한 페이지를 구성하고 쉽고 빠르게 수정할 수 있었다. 금주에는 공휴일이 아예 없어서 다소 걱정했는데...안타깝게도 다른 일정까지 바빠지는 바람에 시간이 매우 촉박하였다. 거기다 이제 젊은 나이가 아니다보니 욕심에 비해 체력도 잘 안따라줘서 진행이 쉽지 않음을 다시금 느끼게 되는 한주였다. 3주차를 돌아보며 개선할 점과 보완할 점을 회고하고자 한다. 3주차 잘한 점그래도 어떻게든 과제를 이번 주 내에는 완료하였다.금주부터는 본격적으로 반응형 작업이 많아져 여러 차례 꼼꼼하게 테스트를 진행하기 위해 노력하였다.배운 내용을 활용하여 다른 스타일의 관리자 페이지 제작을 진행해보았다.금주에는 평일 오전에 이틀은 강의를 수강할 수 있었다.3주차 개선할 점새삼 나이가 느껴지는 한주였는데 3주차에 접어들며 시간도 촉박해지고 회사 업무도 많아지면서 체력적인 한계가 많이 느껴졌다. 공부하려면 체력부터 미리 길러둬야겠다는 생각을 했다...이번 주도 과제를 정해진 요일에 제출하지 못했다. 이제 마지막 한 주가 남았는데 최선을 다해보아야겠다...!

UX/UIUX/UXFigma프로덕트디자인디자인시스템워밍업스터디

홍정훈

[인프런 워밍업 클럽 2기 클린코드&테스트코드] 4주차 발자국

출처: Practical Testing: 실용적인 테스트 가이드1. 학습 내용 요약Persistence LayerData Access의 역할비즈니스 가공 로직이 포함되어서는 안됨Data에 대한 CRUD에만 집중한 레이어Business Layer비즈니스 로직을 구현하는 역할Persistence Layer와의 상호작용(Data를 읽고 쓰는 행위)를 통해 비즈니스 로직을 전개 Presentation Layer외부 세계의 요청을 가장 먼저 받는 계층파라미터에 대한 최소한의 검증을 수행MockMvcMock(가짜) 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크트랜잭션에 대한 이야기readOnly = true읽기 전용CRUD에서 CUD 동작 X / only ReadJPA에서 CUD 스냅샷 저장, 변경감지 X → 성능 향상CQRSCommand와 Read의 분리두 동작이 서로 영향을 주지 않게 분리  Stubbing컴포넌트를 MockBean 처리하고 동작에 대한 가짜 행위를 정의하는 것Test Double Dummy아무 것도 하지 않는 깡통 객체Fake단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체Stub테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체그 외에는 응답하지 않음SpyStub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있음Mock행위에 대한 기대를 명세하고그에 따라 동작하도록 만들어진 객체 한 문단에 한 주제 논리 구조가 들어가지 않는 형태로 구성하는 것이 좋음Parameterize Test케이스 테스트 코드를 각각 따로 작성완벽하게 제어하기제어할 수 없는 것들은 상위 계층으로 분리해서 테스트 가능하게테스트 환경의 독립성을 보장하자 테스트 간 독립성을 보장하자테스트 간에는 순서가 없어야 함공유 자원을 사용하는 경우 테스트 간 순서가 생길 수 있음한 눈에 들어오는 Test Fixture 구성하기Fixture고정물, 고정되어 있는 물체테스트를 위해 원하는 상태로 고정시킨 일련의 객체 중복으로 세팅하는 경우에는 셋업에서 구성을 하면 어떨까공유 객체를 사용하는 것과 동일한 효과를 가져올 수 있음 테스트와 결합도가 생김코드가 길어지면 의도가 한 눈에 보이지 않을 수 있음 data.sql 같이 셋업을 다른 파일에 옮기면 픽스쳐의 파편화가 일어날 수 있기에 지양빌더를 생성할 땐 파라미터에 테스트에서 필요한 것만 남겨놓자클렌징DeleteAll() Vs. DeleteAllInBatch()DeleteAll()은 각 엔티티를 개별적으로 삭제하며, 삭제 전 select 쿼리를 실행대신 지우는 순서가 상관없어질 수 있음물론 항상 되는 것은 아님DeleteAllInBatch()는 단일 쿼리로 모든 데이터를 삭제하여 더 효율적대량의 데이터를 처리할 때는 DeleteAllInBatch()가 성능상 유리할 수 있음 @DynamicTest어떠한 시나리오를 기반으로 상태를 공유하면서 테스트를 진행할 수 있음테스트 환경 통합테스트 환경을 통합하여 테스트 성능 최적화환경이 다르면 서버가 테스트마다 새로 떠야함  Rest Docs Vs. SwaggerRestDocs장점테스트를 통과해야 문서가 만들어짐 (신뢰도 증가)프로덕션 코드에 비침투적단점코드 양이 많음설정 어려움Swagger장점적용이 쉬움문서에서 바로 API 호출을 수행해볼 수 있음단점프로덕션 코드에 침투적테스트와 무관하기 때문에 신뢰도가 떨어질 수 있음2. 미션 회고Day 15. Layered Architecture 구조의 레이어별 특징을 정리하고, 어떻게 테스트 하면 좋을 지 정리하는 미션이었다. Persistence Layer, Business Layer, Presentation Layer 역할에 대하여 다시 정리해보고, 레이어의 특징에 따른 테스트 코드 예시를 정리해볼 수 있는 기회였다.미션 링크: https://www.notion.so/Day-15-1275cf1d569e8067b43ef2245e1f74ecDay 18. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks의 차이를 정리하고, 주어진 테스트 코드를 리팩토링하는 미션이었다. 강의 시간에 다루었던 어노테이션들에 대해서 자세히 알아볼 수 있었다. 또한, 코드를 리팩토링하며 강의에서 배웠던 내용들을 응용해 볼 수 있었다.미션 링크: https://www.notion.so/Day-18-12a5cf1d569e804e8012f4021394b5bd 3. KPTKeep시험 기간이 겹쳤지만, 과제와 진도를 밀리지 않고 잘 수행하였다. Try 학습했던 내용들을 앞으로 잘 활용하여, 한층 더 성장한 개발자가 되어야겠다.4. 느낀점4주간의 워밍업 클럽 일정이 마무리되었다. 처음 워밍업 클럽을 알게 되었을 때, 테스트에 대해 깊이 있게 학습할 수 있는 좋은 기회라고 생각하여 신청했다. 그러나 클럽 활동을 통해 다양한 지식과 기술을 배울 수 있었을 뿐만 아니라, 다른 참가자들의 코드와 질문들을 보면서 새로운 시각을 갖게 되고, 많은 자극을 받을 수 있었다. 다음 워밍업 클럽이 열린다면, 한번 더 참가하고 싶다.

프로그래밍 언어

인프런 워밍업 클럽 4주차 발자국

4주차 강의 정리Presentation Layer -> 사용자와 시스템 사이의 외부 값을 검증@WebMvcTestMockingMockMvc@Mock@MockBean@InjectMocks@Spy@SpyBeanLayer별 DTO -> 모듈 분리시 의존성 문제 가능성 제거, 책임 분리@Transactional@Transactional(readOnly=true)긴 작업일때는 지양 @Valid@NotNull@NotEmpty@NotBlank Test DoubleDummyFakeStubSpyMockBDDMockitoClassicist -> 실제 모듈을 사용해서 통합 테스트 지향Mockist -> 기능 보장된 것은 제외하고 빠른 테스트 지향테스트의 목적은 하나로 하는게 좋다.제어 가능한 영역으로 분리하여 테스트테스트 독립성 테스트에 영향을 주는 다른 요소 제거테스트간 공통 의존 제거Test Fixture@BeforeEach는 테스트 로직과 관련성이 적은 요소 위주테스트는 문서다 -> 정보의 파편화 발생 가능성테스트 환경 통합 -> 테스트를 위해 Spring Boot 실행 횟수를 감소시키는 방향으로 4주차 강의 회고좋았던 점실무에 적용되는 테스트 팁을 알 수 있었다.명확한 테스트 방법에 대해 생각해볼 수 있었다. 아쉬웠던 점특별 라이브에 참석하지 못한 점이 아쉽다.배운 점Spring 진영의 테스트 세부 기능명확한 테스트 문서 작성 방법 앞으로 바라는 점미션Day15https://lapis-dew-01f.notion.site/Day15-1267d24093d680bb8d2ed4c5e35a6a5b?pvs=74Day18https://lapis-dew-01f.notion.site/Day18-12a7d24093d680659325ed3c31986b56

유진

인프런 워밍업 클럽 BE 2기 - 클린코드 / 테스트코드 발자국 4주차

강의 출처 Practical Testing: 실용적인 테스트 가이드 학습 내용레이어드 아키텍쳐(Layered Architecture)와 테스트 - 노션 정리Test DoubleDummy - 아무것도 하지 않는 깡통 객체.Fake - 단순한 형태로 동일한 기능은 수행하나, 프로덕션 초기에는 부족한 객체.Stub - 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체. 그 외에는 응답하지 않는다.Spy - stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체. 일부는 실제 객체처럼 동작하고 일부만 stubbing 할 수 있다.Mock - 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체.Stub / Mock 의 차이? -> Stub은 상태 검증 / Mock은 행위 검증@Mock, @Spy, @MockBean, @SpyBean, @InjectMocks - 노션 정리BDDMockito - Mockito를 BDD 스타일로 wrap해서 사용.// given Mockito.when(mailSendClient.sendEmail(anyString(), anyString(), anyString(), anyString())) .thenReturn(true); // BDDMockito given BDDMockito.given(mailSendClient.sendEmail(anyString(), anyString(), anyString(), anyString())) .willReturn(true);Classicist VS. Mockist진짜 객체로 테스트를 하고 필요한 경우에만 mocking해서 테스트를 하자. (Classicist)외부 시스템의 경우 mocking 처리해서 테스트.하나의 테스트는 하나의 주제만을 가져야 한다. 논리구조(if문, for문..) 같은 경우는 지양하는 것이 좋다. 만약 케이스 확장이 필요하다면 @ParameterizedTest 사용. 테스트 환경의 독립성 보장 - given절에서는 값 넣어줄 때 생성자, builder 사용.테스트 간 독립성 보장 - 두 가지 이상의 테스트가 하나의 자원을 공유할 때 주의해야 한다. 공유 자원(인스턴스)의 여러 시나리오를 테스트 하고 싶을 경우? -> @DynamicTest 사용.Test Fixture각각의 테스트에서 given이 중복되는 경우 @BeforeEach 에 작성할 경우 주의 해야 할 점 -> 각 테스트 입장에서 알지 못해도 테스트 내용을 이해하는데 문제가 없는지 / 수정해도 모든 테스트에 영향을 주지 않는지 고려해야 한다.data.sql 사용 지양. -> 무엇을 테스트하고 있는지 파악하기 어려울 수 있다.테스트 클래스마다 builder를 만들어서 각자 필요한 파라미터만 사용한다. (builder class를 만들어서 한 곳에서 관리하는 것이 오히려 복잡도를 늘어나게 한다.)Test Fixture 클렌징deleteAll()mapping된 테이블을 조회 후 delete 한다. 연관된 테이블을 모두 조회한 후 삭제하기 때문에 시간과 비용이 들 수 있다.테이블의 삭제 순서를 고려해야 될 수 있다.deleteAllInBatch()테이블의 삭제 순서를 고려해야 한다.여러 조건들(외래키 조건..)에 따라 삭제가 되지 않을 수 있다.테스트 환경 통합하기ServiceTest, RepositoryTest@ActiveProfiles("test") @SpringBootTest public abstract class IntegrationTestSupport { @MockBean protected MailSendClient mailSendClient; }ControllerTest@WebMvcTest(controllers = { OrderController.class, ProductController.class }) public abstract class ControllerTestSupport { @Autowired protected MockMvc mockMvc; @Autowired protected ObjectMapper objectMapper; @MockBean protected OrderService orderService; @MockBean protected ProductService productService; }private 메서드의 테스트는 하지 말아야 한다. 꼭 해야 된다면 따로 객체를 분리해서 테스트를 할 수 있다.테스트에서만 필요한 메서드는 만들어도 되지만, 보수적으로 접근해야 한다. 미션미션 1 - Layered Architecture 구조의 레이어별 특징과 테스트 작성법 -> 노션 정리미션 2 - @Mock, @Spy, @MockBean, @SpyBean, @InjectMocks 차이점 / @BeforeEach 배치 -> 노션 정리회고인프런 워밍업 클럽 BE 2기 4주차라니 시간이 어떻게 흘러간지 모르겠다. 이번 주는 특히나 내가 평소 궁금했던 것들에 대한 강의여서 더 집중해서 들었던 것 같다. 바로 프로젝트에 적용 해볼 만 한 내용이 많아서 만족스러웠다. 워밍업 클럽 진도를 따라가는게 쉽지는 않았지만 지나고 보니 포기하지 않고 어떻게든 하려고 노력 했던 것이 많은 도움이 된 것 같다.

백엔드인프런워밍업클럽2기테스트

허수빈

[인프런 워밍업 클럽 2기 클린코드 & 테스트 코드] 4주차 발자국

해당 글은 [인프런 워밍업 클럽 2기 클린 코드 & 테스트 코드]에 참가하여 박우빈님의 <Readable Code: 읽기 좋은 코드를 작성하는 사고법> 강의를 듣고 작성한 글입니다. ✍ 이번주 강의 요약Spring & JPA 기반 테스트서비스의 핵심 로직이 있는 Business Layer는 여러 시나리오에 따라 다양하게 테스트를 진행해야 한다.외부세계의 요청을 가장 먼저 받는 Presentation Layer는 클라이언트로부터 넘겨 받은 값들에 대한 유효성 검증을 수행해야 한다.Mock을 마주하는 자세@Mock은 가짜 객체@MockBean은 스프링 빈으로 등록되는 가짜 객체@Spy는 실제 객체의 특정 메서드를 모킹, 변경 가능.@SpyBean은 스프링 빈으로 등록된 실제 객체의 특정 메서드를 모킹, 변경 가능7 ~ 9. 테스트 코드는 한 문단 당 한 주제를 담자!독립적이어야 하고 순서가 있으면 안된다.테스트 코드는 프로덕션 코드의 문서화다.귀찮음을 이겨내고 제대로 작성해야 한다! 🏃 미션Day15사실 강의만 들었을 때는 이해가 잘 안돼서 여기 저기 찾아보고 정리했다. 아직도 완벽한 건 아니고 실제로 내가 프로덕션 코드를 짜고 테스트 코드를 짜야만 완전히 이해할 수 있을 것 같은 느낌이다... ㅜ Day18다른 사람이 테스트 코드를 볼때 정말 없어도 되는, 해당 코드가 있든 말든 테스트 코드 자체를 읽는 데는 문제 없는 부분만 setup에 넣어야 한다고 생각해서 준비 내용만 setup으로 뺐는데 좀 더 고민해보니까...void writeComment() : 댓글 작성void updateComment() : 댓글 수정void cannotUpdateCommentWhenUserIsNotWriter() : 타인의 댓글 수정 시도 실패해당 주제를 파악하는데만 필요한 것들을 given 절에 두고 나머지는 setup으로 빼도 되지 않을까? 댓글 작성이나 댓글 수정은 댓글을 쓰고 수정하는 것이 목적이니까 사용자 생성이나 게시글 생성 같은 것도 setup에 둬도 될 것 같다.. 🗒️ 회고드디어 약 한 달간의 여정이 끝났다. 나 혼자 강의를 수강했다면 훨씬 더 오래 걸렸을텐데 계획이 짜여져 있고 미션을 수행해야하니까 좀 더 빠르게 들을 수 있던 것 같다. 결코 쉬운 과정은 아니었지만... 복습해야하지만... ㅜㅜ 그래도 완강했으니까 뿌듯하다!아주 조금씩이지만 성장하는 게 느껴진다. 나태해지지 말고 남은 2024년도 열심히 보낼 수 있기를! 마지막으로 좋은 강의를 제작해주신 박우빈님께 감사인사 드립니다.

웹 개발워밍업클럽

Rojojun

[워밍업 클럽 스터디 2기::백엔드] 4주차 발자국

1주일간의 학습 회고이미 3주차에 완강을 했기 때문에, 이번주에는 집중적으로 학습하려고 했던 계획은 실제 회사 프로덕트 코드에서 녹여내기와 함께 숙제였다.하지만, 장례식으로 인해서 제대로 되지 못했다.이번주 상을 치루는 동안 공부 + 프로덕트 녹여내기를 시작했다.이번주는 학습보다 허무주의와 하루하루 더 열심히 살자 이 두 가지에서 고민을 했던거 같다... 이제부터 나의 마지막 학습 회고를 적으려고 한다.숙제1Q. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.사실 강의를 보면서, 이것들의 정의를 정리하면서 했기 때문에 쉬운 내용이었다.숙제를 풀기 위해서 중요한 부분은 위의 어노테이션의 차이를 정리하는게 아니라 위 어노테이션들은 Mock 테스트에 사용된다라는 것과 Spring의 중요 개념인 DI에 대해서 세삼 놀랍다고 생각하였다.사실 DI는 Spring에서의 중요 개념이 아닌 대부분의 프로그래밍 언어의 디자인 패턴에서 중요한 개념이다.정리를 하자면 위의 내용에 대해 별도로 이 포스트에서는 정리하지 않겠다.가장 중요한 것은, 이 기술들 사용하는 이유와 이 기술이 쓰이는 원인들이 중요하다고 생각한다. 숙제2두 번째 숙제는 너무 직접적인 내용을 포스트로 올리면 안되기 때문에, 후기로만 대략적으로 적는다면... 쉬웠다!BDD로 테스트코드를 작성해서 그런가... 사실 많이 쉬웠다. 이번 주 학습에서 잘한 점사내에서 백오피스를 혼자서 개발하는데 '나야 TDD, 근데 BDD를 곁들인' 그런 식으로 혼자서 개발하고 동료들에게 공유하고 있었다... 이번 주는 개인적인 일때문에 공유를 많이 못했지만, 디스코드로 소통하면서 공유를 조금씩 하였다.총평회사의 동료들과 처음으로 인프런 워밍업 클럽을 하였다.일단, 회사 동료들과 하는 나는 참 축복받았다는 생각을 하게 되었고, 이 학습을 나만 공부하는게 아닌 다 같이 공유해서 토론하고 발전해 나가는 과정이 좋았다.항상 보고자 했던 강의 였는데 이러한 기회가 생겨서 너무 좋았고....이제는... 개인적인 마음과의 싸움을 시작해야하는 시간이다

테스트코드백엔드SpringJava

[워밍업 클럽 스터디 2기::백엔드] 4주차 발자국

이번주 학습 내용각 컨트롤러, 서비스, DAO 부분에서 테스트 하는 방법을 공부했다.Persistence LayerPersistence Layer란, CRUD 가 일어나는, DataBase 를 통해 값을 저장하거나, 읽어오는 부분의 역할에 대한 테스트 이다.간단한 조건을 통해 (Where 구문이 포함된) 데이터를 조회하게 될 때, 내가 의도한 조건으로 필터링 된 데이터가 잘 도착하는지 검사할 떄나,데이터를 저장하거나, 수정하는 로직의 경우, 어떤 부분을 어떤 방법으로 수정하는지와, 수정된 값이 내가 의도한 대로 잘 작동하는지 확인을 하기 위한 테스트이다.위 테스트는 비지니스에 대한 로직이 포함되어서는 안되며, CRUD 쿼리 자체를 검증하는 부분이라고 봐야한다.Business LayerBusiness Layer 에서는 실제 우리 도메인에서 가진 서비스단에서 수행되는 Business 로직에 대해서 검증하며, Persistence Layer 의 테스트를 포함해 작성하는 것이 좋다.성공 케이스인 A 메소드를 수행해 저장된 값이 1 > 2로 변경되는 부분에 대해서도 당연히 테스트가 진행되어야 하지만, A메소드 수행 도중 예외 상황을 만났을 때, 어떤 메시지를 가진 예외가 발생하는지 까지 테스트에 포함되어야 한다.그리고, 비즈니스 로직을 수행하다가 실패할 경우, 한 단위의 트랜잭션에 포함 시켜, 수행 이전 상태로 돌아가도록 설정해야 한다.추가적으로, 서비스에 대한 설계가 이루어 질때, 항상 요구사항을 정리 후, 테스트 부터 작성하고 예외의 경우는 무엇이 있으며, 해당 상황의 경계값 테스트를 통해 로직에 기반한 테스트를 하지 않도록 가장 주의해서 작성해야 하는 부분이라고 생각한다.Presentation LayerPresentation Layer 에서는 외부 세계로 부터 데이터를 받아오는 Controller 에 대한 테스트를 주로 담고 있으며, 요청되는 파라미터 값에 대한 큰 기준의 유효성 체크 (빈 값이 들어오면 안되는 값) 등에 대한 검증을 할 수 있으며, Controller 계층은 Service 와 의존관계를 거의 항상 맺고있기 때문에, 외부에서 넘어오는 값에 대해 검증을 위해서, 하위 계층에서 일어나는 일들을 Mocking 처리하고, 하위 계층에서 일어날 Business 로직에 대해서는 위 Business Layer 와 Persistence Layer 에서 검증할 수 있도록 한다.위 상황에서 보면, Presentation Layer 와 Business Layer 에서 각각 유효성 체크를 하고 있는 것을 한 곳으로 묶는게 어떨지에 대한 생각이 들 수 있다.하지만, VO 단위에서 예외로 생각되는 부분과 내가 작성한 비지니스 로직에서 생각되는 예외를 분리해 처리함으로 서, 좀더 명확한 Exception Message 를 가진 상세한 예외를 처리할 수 있으며, 동일한 메소드가 재사용 되기 위해서는 VO에서는 특정 비지니스 로직에 종속되지 않은 범용적 예외 상황에 대해서만 처리 되도록 작성해야 하며,이를 항상 염두에 두고 한 설계를 하도록 하자!좋았던점 (Liked)이전에 테스트를 설계하면서 테스트가 어렵다 생각하고, TDD방식을 지키며 하지 못했던 내 사고의 방식이 어떤식으로 변경되어야 하는지 조금은 알아가고 있는 것 같다.아쉬웠던 점 (Lacked)이번주도, 신경쓸 시간이 많이 없어 미션이 아직 밀려 있는 부분이 있다. Day 18 미션은 적어도 월요일까지 스스로라도 완료할 예정이다..배운 점 (Learned)어느정도 범위까지 테스트가 작성되어야 하는지, 내가 작성하면서느낀 테스트의 필요성을 이미 강의에서 설명해주고 계서서 많은 도움이 됬다.앞으로 바라는 점(Longed for)다음주 금요일 이전까지 남은 강의와 미션들을 전부 마무리 해보면서 비록 진도표 대로 따라가진 못했지만, 내 스스로라도 마무리 할 수 있도록 마무리하겠다!

hhw0850

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

Practical Testing: 실용적인 테스트 가이드 수강 후 작성한 4주차 발자국입니다. 4주차 강의 정리 Test DoubleDummy : 아무 것도 하지 않는 깡통 객체Fake : 단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체Stub : 테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체 그 외에는 응답하지 않는다. - 상태 검증 (State Verification)Spy : Stub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체 일부는 실제 객체처럼 동작시키고 일부만 Stubing 할 수 있다.Mock : 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체 - 행위 검증 (Behavior Verification)BDDMockitoMockito에서 BDD 스타일에 맞춰서 작성할 수 있게 끔 도와주는 라이브러리Classicist vs MockistClassicistMocking 처리를 다 하지 말고 진짜 객체로 최대한의 테스트를 해야 한다는 주의Mockist모든 것을 Mocking 위주로 테스트하자. 기능이 보장된 것들은 mocking 처리하고 테스트를 빠르고 간단하게 하자는 주의더 나은 테스트를 작성하기 위한 구체적 조언한 문단에 한 주제테스트는 문서로서의 기능을 한다.하나의 테스트가 한 문단이라고 생각한다면 하나의 테스트는 하나의 주제만을 가져야 한다.완벽하게 제어하기어떤 테스트 환경을 조성하기 위해 완벽하게 제어할 수 있어야 한다.현재 시간, 랜덤 값, 외부 시스템과 연동하는 경우테스트 환경의 독립성을 보장하자테스트 간 결합도가 생기는 경우 독립성을 보장해야 한다.테스트 간 독립성을 보장하자두 개 이상의 테스트에 대한 독립성을 보장해야 한다.한 눈에 들어오는 Test Fixture 구성하기테스트를 위해 원하는 상태로 고정시킨 일련의 객체given절에서 생성했던 모든 객체들을 의미한다Test Fixture 클렌징deleteAll vs deleteAllInBatch@ParameterizedTest하나의 테스트 케이스인데 값을 여러 개로 바꿔보면서 테스트를 하고 싶을 때 사용하면 좋은 테스트@DynamicTest어떠 환경을 설정해놓고 이 환경에 변화를 주면서 테스트하고싶을때 사용하면 좋은 테스트private 메서드는 테스트할 필요가 없다.테스트에서만 필요한 메서드 중 생성자 등은 프로덕션 코드에 생성해도 좋다. 4주차 회고이번 워밍업 클럽에 참여하면서 느낀점 한 가지는 '조금이더라도 계속해서 공부하자'이다. 워밍업 클럽에 참여하면서 지식을 많이 얻어갔다고는 못하겠지만 확실한건 공부에 대한 동기부여가 됐다. 이번 테스트 코드 강의를 들으면서 테스트 코드 자체를 처음 작성해보고 JPA도 처음이어서 강의를 보긴 했어도 100퍼센트 이해하진 못했다. 그래서 이번 워밍업 클럽이 끝난 후엔 JPA 스프링 자바에 대한 공부를 더 해야겠다고 생각했다. 부족한 점이 너무너무 많다고 느껴서 퇴근 후에 조금이라도 공부해서 실력을 꾸준히 쌓을 것이다.

jenhuhh

인프런 워밍업 프로덕트 디자인 2기 4주차 발자국

네번째이자 마지막 발자국지난 이커머스 b2b 화면에 이어 이때까지 만들었던 컴포넌트를 활용하여 b2c 이러닝 페이지와 모바일 OTT 서비스 페이지를 만들었다. 특히 내가 평소에 부족했다고 느꼈던 부분들, 반응형 구조라던지, 다크모드 활용하기 등을 집고 넘어갈 수 있는 미션이여서 특히나 도움이 많이 되었고, 무엇보다 너무 재밌었다! 확실히 기초를 잘 다듬어 놓으니 레고 블럭처럼 뚝딱뚝딱 조립해 나가는 재미가 있었다.모바일 OTT를 만들면서 플러그인 하나가 말썽을 부렸는데, 볼드님이 원인 파악을 해주셔서 말끔하게 완성시킬 수 있었다!온라인 세션해당 강의에서 프로토타이핑을 배울 줄은 생각도 못했는데, 온라인 세션 공지를 보고 너무너무 반가웠다. 이때까지는 화면을 연결하는 수준으로만 프로토타이핑을 했었고, 베리어블을 활용한 프로토타이핑은 그저 어렵다고만 생각했었다. 그런데 오늘 세션을 통해 메커니즘을 이해하고 나니, (여전히 어렵지만..!) 활용해 볼 수 있는 용기가 생긴 것 같다. 볼드님이 공유해주신 족보를 보며 계속계속 복습해 봐야겠다.스터디를 마무리하며스터디를 시작하기전에 회사 업무와 같이 병행할 수 있을까 걱정이 앞섰는데, 너무너무 잘 한 결정이라고 생각한다. 가끔씩은 빨리 퇴근하고 집에가서 강의듣는 시간이 더 기다려졌을 정도!! 특히, 가장 좋았던 점은 중간중간 진행한 라이브 온라인 세션이었다. 온라인 세션때마다 피그잼에서 만나는 다른 러너분들도 너무 반가웠고, 혼자가 아니라는 느낌을 받아서 의지가 많이 되었던 것 같다.이제부터가 진짜 시작이라 생각하고 강의 시작할 때 다짐했던 '내 것으로' 만들기 위해 계속 복습하고, 실무에 적용해보는 일만 남은 것 같다.한달동안 함께 고생해주신 볼드님께 무한한 감사드립니다!

UX/UI

김민성

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

인프런 워밍업 클럽 스터디 2기 - 백엔드 클린코드, 테스트 코드(Java, Spring Boot)Practical Testing: 실용적인 테스트 가이드해당 강의를 학습하며 정리하는 내용입니다. 드디어 마지막 주차 발자국을 작성하는 시간이다. 이번주에는 Mock관련 내용과, 테스트를 작성하기 위한 팁, Spring REST Docs에 대해 배우는 주차였다. Mock을 마주하는 자세Test Doble외부 API같이 내가 직접 테스트 하기 어려운 것들을 가짜로 대체해서 테스트 하는 테스트 방법론Dummy아무것도 하지 않는 깡통 객체Fake단순한 형태로 동일한 기능은 수행하나, 프로덕션에서 쓰기에는 부족한 객체 (ex. FakeRepository)Stub테스트에서 요청한 것에 대해 미리 준비한 결과를 제공하는 객체. 그 외에는 응답하지 않는다.SpyStub이면서 호출된 내용을 기록하여 보여줄 수 있는 객체일부는 실제 객체처럼 동작시키고 일부만 Stubbing할 수 있다.Mock행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체Stub : 상태 검증 (State Verification)Mock : 행위 검증 (Behavior Verification) Classicist VS. Mockist라는 말을 처음 들어봤는데, 실제 객체로 통합 테스트를 해가면서 필요할 때만 Mocking해서 사용하자는 Classicist파와, 각각 따로따로 다 목킹해서 순수 코드만 빠르게 테스트 하자 라는 Mockist파의 싸움 같은 거다.나도 이에 대해 생각을 해봤는데, 나는 Mockist에 좀 더 가까운 거 같다. Mockist가 좀 더 뭔가 작은 블럭을 쌓아가서 전체를 만드는 느낌이 든다.하지만 분명히 Mockist여도 통합테스트 해야하고 Classicist여도 목킹을 통한 단위테스트는 해야한다. @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks이거에 관하여 미션이 나갔다. @Spy는 진짜 처음봐서 좋은 기능 배웠다고 생각한다.day-18 미션그리고 테스트 분류 미션에 관해서도 깜짝 라이브를 통해 우빈님의 의도를 들었었는데, setUp, given, when, then에 두어야 할 것에 대한 생각을 정리할 수 있게 된것 같다.더 나은 테스트를 작성하기 위한 구체적 조언여기서는 다양한 테스트 꿀팁들을 배웠다.키워드한 문단에 한 주제글쓰기와 같다. 한 테스트에 한 주제완벽하게 제어하기LocalDateTime.now() 같이 달라질 수 있는 값들은 사용하는 것을 지양하자.테스트 환경의 독립성을 보장하자지금 하고 있는 테스트의 주제를 잘 생각하고, when, then절이 아닌 다른 곳에서 테스트가 깨지지 않도록 하자.테스트 간 독립성을 보장하자A → B, B → A 순서가 바뀐다고 테스트가 바뀌면 안된다.한 눈에 들어오는 Test Fixture 구성하기given절에 생성한 모든 객체들Test Fixture 클렌징deleteAllInBatch() vs deleteAll() vs @Tranjactional@ParameterizedTestif 분기문, 반복문 등 → 생각의 사고를 추가 해야 하는, 즉 읽기 힘든 테스트가 된다. 값이나 환경만 바꿔가면서 테스트를 여러번 반복 하고 싶을 때 사용하면 좋다.@DynamicTest일련의 시나리오를 테스트 하고 싶을 때가 있다. 그럴때 사용하면 좋은게 @DynamicTest이다.테스트 수행도 비용이다. 환경 통합하기@SpringBootTest를 사용할 때 조금이라도 프로파일이라던지 이런 설정이 달라지면 다 다른 설정으로 스프링이 올라간다.Q. private 메서드의 테스트는 어떻게 하나요?결론은 안하는게 맞다.Q. 테스트에서만 필요한 메서드가 생겼는데 프로덕션 코드에서는 필요 없다면?만들어도 된다. 하지만 보수적으로 접근하기!하나 같이 막힐때 큰 도움이 될 거같은 조언이다.Appendix학습 테스트잘 모르는 기능, 라이브러리, 프레임워크를 학습하기 위해 작성하는 테스트여러 테스트 케이스를 스스로 정의하고 검증하는 과정을 통해 보다 구체적인 동작과 기능을 학습할 수 있다.관련된 문서만 읽는 것보다 훨씬 재미있게 학습할 수 있다.Spring REST Docs테스트 코드를 통한 API 문서 자동화 도구API 명세를 문서로 만들고 외부에 제공함으로써 협업을 원활하게 한다.기본적으로 AsciiDoc을 사용하여 문서를 작성한다.REST Docs장점테스트를 통과해야 문서가 만들어진다. (신뢰도가 높다.)프로덕션 코드에 비침투적이다.단점코드 양이 많다.설정이 어렵다.Swagger장점적용이 쉽다.문서에서 바로 API 호출을 수행해볼 수 있다.단점프로덕션 코드에 침투적이다.테스트와 무관하기 때문에 신뢰도가 떨어질 수 있다. Spring REST Docs는 문서화를 도와주는 도구인데 설정이 좀 많이 어려운 듯 하다. 추가적인 공부가 많이 필요한 것 같다.한번은 배워보고 싶은 도구였어서 좋은 계기였다.전체 회고드디어 4주의 학습 스터디가 끝났다. 개인적으로 퇴사를 앞두고 있는데, 이제서야 이런 좋은 학습 기회가 있다는 것을 알아서 좀 아깝지만 늦었다고 생각할 때가 가장 빠르니까 좋게 생각한다.2년동안 개발을 하면서 테스트나 클린 코드를 생각안해본건 아닌데, 솔직히 현재 업무에서 살짝살짝 내가 혼자 학습해서 조금씩 적용해본 정도지, 진지하게 공부하고 사용해 본적은 없었다.이번 강의가 클린코드, 테스트 코드 두 강의나 돼서 좀 듣기 빡세긴 한데, 진짜 도움이 많이 되는 것 같았다. 클린 코드는 내가 코드를 보는 생각이 좀 더 열린 계기가 된 것 같고, 테스트 코드는 평소에 배우고 싶다는 갈망이 많이 채워졌다.앞으로 두 내용에 대해 좀 더 학습해 나아가면서 지금 배웠던 것들이 기초가 될 것이라고 생각한다. 다음에도 이런 좋은 주제가 있으면 언제든지 참가하고 싶다. 

백엔드워밍업클럽테스트코드클린코드백엔드

vin

[인프런 워밍업 클럽 BE 2기] 백엔드 프로젝트 - 4주차 발자국

마지막 주차인 4주차는 지금까지 개발한 어디민 페이지의 뷰를 개발하였고, 스프링 시큐리티를 이용한 로그인 개발, 로그 저장 등의 기능을 구현 하였다. 프로젝트를 마무리 짓고 최종적으로 docker와 구글 클라우드를 이용해서 배포를 하였다. 어드민 화면 개발 1부트스트랩 템플릿 적용 시 코드 분석 및 TODO 체크 기능 해제: 부트스트랩 템플릿을 사용해 UI를 구성할 때 코드 변경 사항이 많아 analyze code와 check TODO 기능이 오래 걸려, 이를 해제하여 커밋 및 푸시 시간을 줄임.사이드바 개발에서 th:classappend, th:attr data-bs-target, th:classappend show 사용: Thymeleaf의 th:classappend를 이용해 동적으로 클래스를 추가하고, th:attr을 통해 부트스트랩의 data-bs-target 속성을 설정하여 UI 요소를 제어함. show 클래스를 사용해 사이드바를 열고 닫는 동작을 구현.뷰 레이아웃 개발 및 테이블 페이지(Table) 구현: HTML 템플릿에서 레이아웃을 설계하고, 데이터가 표시될 테이블 형태의 페이지를 구성. 이를 통해 표 형태로 데이터를 보기 쉽게 표시./*<![CDATA[*/ 구문 사용과 [[${pageName}]] 바인딩: Thymeleaf에서 스크립트를 안전하게 사용하기 위해 CDATA 구문을 사용하고, ${pageName}을 통해 페이지 이름을 동적으로 바인딩하여 화면에 표시.테이블 아이디 tableName 설정: HTML에서 테이블을 식별하기 위한 아이디를 tableName으로 설정하여 JavaScript 등에서 쉽게 접근 가능하도록 함. 어드민 화면 개발 2테이블 페이지(Form) 개발: 사용자가 데이터를 입력하고 제출할 수 있는 Form 페이지를 구성. 입력된 데이터를 서버로 전송하고 처리하는 역할을 함.onsubmit : Form이 제출되기 전에 특정 JavaScript 함수를 실행하여 데이터를 검증하거나 추가 작업을 수행할 수 있게 해주는 이벤트.대시보드와 로그인 기능 개발스프링 시큐리티를 이용한 로그인 개발: 스프링 프레임워크에서 제공하는 시큐리티 모듈을 사용해 사용자 인증 및 권한 관리를 구현. 안전한 로그인 기능을 제공.패스워드 인코더 및 필터 체인 개발: 패스워드 보안을 위해 PasswordEncoder를 사용해 비밀번호를 암호화하고, 인증 과정을 제어하기 위해 필터 체인을 설정함.AntPathRequestMatcher 사용: 특정 URL 경로와 HTTP 메서드에 대해 시큐리티 필터링을 설정하는 데 사용. 로그아웃 등의 특정 경로에 대해 시큐리티를 설정할 때 유용함.구글 클라우드 플랫폼으로 프로젝트 배포Docker로 MySQL 실행 및 컨테이너 설정: Docker 이미지를 사용해 MySQL 데이터베이스를 컨테이너로 실행하고, 필요한 포트와 환경 변수를 설정하여 데이터베이스를 관리.ports, command, volumes 설정:ports: 호스트와 컨테이너 간의 포트를 매핑하여 외부에서 데이터베이스에 접근할 수 있도록 함.command: 컨테이너가 시작될 때 실행할 명령어를 정의. 예를 들어, MySQL의 문자 집합을 설정하는 명령어를 추가.volumes: 컨테이너의 데이터가 호스트에 영구적으로 저장되도록 설정하여 컨테이너 재시작 시 데이터가 손실되지 않도록 함.프로젝트 컨테이너 설정 및 depends_on 사용: Spring 애플리케이션을 실행하는 컨테이너와 데이터베이스 컨테이너를 설정하고, depends_on을 통해 MySQL이 먼저 실행된 후 애플리케이션이 실행되도록 순서를 지정.호스트 포트 (Host Port): 호스트 컴퓨터에서 사용되는 포트입니다. 예를 들어, 3306:3306에서 앞의 3306이 호스트 포트입니다. 이는 Docker를 실행하는 컴퓨터에서 접근 가능한 포트 번호를 의미합니다. 다른 컴퓨터나 서버에서 이 호스트의 IP 주소와 포트를 사용하여 Docker 컨테이너의 서비스에 접근할 수 있습니다.컨테이너 포트 (Container Port): 컨테이너 내부에서 서비스가 실행되는 포트입니다. 3306:3306에서 뒤의 3306이 컨테이너 포트입니다. 이는 컨테이너 내부에서 MySQL 서비스가 동작하는 포트를 의미합니다. 컨테이너 내의 애플리케이션은 이 포트를 통해 데이터베이스와 통신합니다.Docker로 프로젝트 빌드Google Cloud Platform에서 Compute Engine 인스턴스 생성: 애플리케이션을 배포할 가상 머신을 생성하여, Docker 컨테이너를 실행할 환경을 제공.도커 허브로 푸시 시 커맨드로 진행: Docker Desktop에서 푸시 시 발생하는 오류를 해결하기 위해 명령어를 사용하여 직접 푸시.Compute Engine에서 도커 컨테이너 실행: Google Cloud에서 생성한 인스턴스에 도커 컨테이너를 실행하여 애플리케이션을 운영.메모리 스왑 설정 및 Nginx 사용: 하드디스크의 일부를 메모리처럼 사용하는 메모리 스왑을 설정하고, Nginx를 사용해 애플리케이션의 로드 밸런싱 및 리버스 프록시 역할을 설정.도메인 연결 및 HTTPS 적용: 애플리케이션에 도메인을 연결하고 SSL 인증서를 적용하여 HTTPS를 통해 안전하게 서비스.[미션 6] MySQL에 내 데이터 넣기문제 상황: Docker로 실행한 MySQL과 DBeaver에서 연결된 데이터베이스의 내용이 달랐음.원인: 과거 MariaDB 사용 이력이 있어, MariaDB와 MySQL이 서로 다른 포트로 연결되어 데이터가 불일치.DBeaver에서는 MariaDB에 연결되고, Docker에서는 MySQL에 연결되는 상황 발생.해결 방법: MariaDB의 서비스를 중단하여 MySQL만 실행되도록 설정하여 문제를 해결.[미션 7] 내 포트폴리오 도메인 공유하기문제 상황: Google Cloud Compute Engine에서 Docker Hub의 이미지를 pull하려 했으나, Docker push가 되지 않아 pull이 실패.원인: Docker Desktop 4.3.3 버전 이후로, Docker Desktop을 통한 push에서 오류 발생.해결 방법: Docker Desktop 대신 명령어를 사용해 push하여 문제를 해결.

웹 개발워밍업클럽백엔드프로젝트웹개발백엔드

vin 25일 전

[워밍업 클럽 2기 - Clean Code & Test Code] 4주차 발자국

워밍업 클럽 2기: Clean Code & Test Code의 4주차 발자국 작성입니다.3주차 발자국 보러가기 📝 학습 내용Presentation Layer 테스트 작성Mock더 나은 테스트를 작성하기 위한 여러 팁REST Docs ✍ 학습 내용 복습Q. Presentation Layer의 특징은?클라이언트로 부터 입력을 받아서 비즈니스 계층으로 해당 요청을 보내는 계층요청을 제일 먼저 받는 계층입력 데이터에 대한 기본적인 검증을 수행한다Presentation 계층에서의 검증과 Business 계층에서의 검증을 분리해서 생각해야 한다Presentation 계층에서는 보통 형식적인 검증을 한다예시: 필수 입력 값 검사, 데이터 타입 검사, null 검사, 빈 문자열 검사Business 계층에서는 비즈니스 로직에 따른 도메인 유효성 검사가 이루어진다Business 계층으로 부터 결과를 받아서 클라이언트로 반환한다컨트롤러에서 사용하는 요청 DTO가 서비스 계층으로 침투하지 못하도록 컨트롤러 계층에서 서비스 전용 DTO로 변환하는 것을 권장한다(상황에 따라 다를 수 있을것 같다. 만약 받는 포맷이 변할 가능성이 거의 없다면, 그냥 컨트롤러의 DTO를 쭉 사용해도 괜찮지 않을까 생각이 된다.)Q. Presentation Layer의 테스트 방법은?Business, Persistence 계층을 모킹해서 테스트한다MockMvc 같은 도구를 사용해서 HTTP요청과 응답을 시뮬레이션 한다모킹을 위해서 Mockito 같은 프레임워크를 사용할 수 있다 Q. Test Double의 종류를 정리해보자면?Dummy: 아루런 동작도 하지 않는 객체. 잘 사용되진 않지만, 보통 파라미터 전달용으로 사용된다.Fake: 실체 객체와 동일한 기능은 수행하지만, 프로덕션 용도로 사용하기에는 적합하지 않은 객체.예시: 인메모리로 맵을 사용해서 가짜 레포지토리를 구현하는 경우Stubs: 테스트에서의 요청에 대해 미리 준비된 결과를 제공하는 객체. 미리 반환할 데이터가 정의되어 있고, 호출하는 경우 해당 데이터를 반환한다. 미리 정의되어 있지 않은 것들은 응답하지 않는다.Spies: Stub이지만 정복 기록도 함께하는 객체. 호출 여부, 호출 횟수 등의 정보를 기록할 수 있다. 일부는 실제 객체 처럼 동작하고, 일부는 Stubbing할 수 있다.Mocks: 행위에 대한 기대를 명세하고, 그 명세에 따라 동작되도록 설계 된 객체. 그러니깐 개발자가 직접 그 객체의 행동을 관리하는 객체이다.Q. Stub과 Mock을 구분하는 기준은?Stub : 상태 검증(State Verification)Mock : 행동 검증(Behavior Verification) TIP. 테스트 작성을 위한 여러 팁을 정리해보면Mockito 프레임워크를 한번 래핑하는 BDD Mockito 프레임워크를 사용해서 조금 더 자연스러운 API 네이밍으로 프레임워크를 사용할 수 있다테스트 간의 독립성을 보장하자 테스트에서 전역 변수를 정의해서 사용하는 것은 권장하지 않는다@BeforeEach또는 @AfterEach 메서드를 사용한 레포지토리 클렌징@Transactional사용 Test Fixture용 클래스를 따로 분리해서 사용하는 것은 권장하지 않는다Test Fixture를 @BeforeEach를 사용한 셋업 메서드에서 사용하는 경우, 중복 제거보다 해당 테스트에 해당 내용을 알아야하는지 고려해보고 적용하자테스트 내용은 동일한데 입력값만 변경해보면서 테스트 해보고 싶으면 @ParameterizedTest 사용private메서드에 대한 테스트가 필요하다면 해당 메서드의 책임을 분리할지 고민해본다단순히 테스트하기 위해서 public으로 열어두는 것은 권장하지 않는다 Q. REST Docs vs Swagger의 차이는?REST Docs테스트를 통과해야 문서가 만들어지기 때문에 신뢰도가 높다프로덕션 코드에 비침투적이다코드의 양이 많고 설정이 상대적으로 어렵다Swagger적용이 쉽다문서에서 바로 API 호출이 가능하다애노테이션을 달아줘야 하기 때문에 프로덕션 코드에 침투적이다🤔 회고워밍업 클럽의 마지막 주차가 되었다. 강의 양이 많아도 내가 정말 필요한 내용을 담아서 만들어져있어서, 시간 가는 줄 모르고 시청했다.강의와 미션을 따라가면서 학습에 많은 도움을 받았다. 만약 워밍업 클럽 3기가 있다면 다시 참가할 예정이다.지금까지 학습 내용을 다시 복습해보고 더 나아가서 프로젝트에 적용하는 것이 목표이다. 🔍 참고Practical Testing: 실용적인 테스트 가이드

백엔드테스트코드워밍업클럽2기백엔드발자국4주차회고

dd

발자국 4주 차

본 내용은 인프런 워밍업 클럽 스터디를 진행하면서 작성한 회고 글 입니다.강의: Practical Testing: 실용적인 테스트 가이드학습 정리Presentation Layer TestPresentation Layer는 외부 세계의 요청을 가장 먼저 받아서 파라미터에 대한 최소한의 검증을 수행하는 계층이다.레이어가 얇고 하는 일이 간단하기 때문에, 하위 레이어(business, persistence)는 mocking을 한다.MockMvc, WebMvcTest를 활용하여 테스트를 작성하자.검증은 그 값이 마땅히 가져야 하는 속성에 대해서만 진행하고, 도메인 성격에 맞는 특수한 형태의 검증은 하위 레이어에서 진행한다.Request 받은 DTO를 서비스로 그대로 넘기면 두 레이어간 의존성이 생긴다. 서비스용 DTO를 따로 만들어서 사용하자.MockClassicist 관점에서 Mocking을 하는 시점은 다음과 같다.우리가 개발하지 않은 외부 시스템외부 시스템을 Mocking하고, 외부 시스템이 정상이거나 비정상 동작했을 때 테스트를 작성하자.그 외에는 실제 프로덕션 코드에서 런타임 시점에 일어날 일을 정확하게 Stubbing 했다고 단언하기 힘들기 때문에 비용이 더 들더라도 실제 구현체를 불러와서 테스트하자.메일전송 같은 긴 네트워크를 타는 로직에는 transaction을 붙이지 않는 게 좋다.DB 커넥션을 계속 점유하기 때문만약 메일 전송 이후에 해야하는 작업이 여러개이고, 트랜잭션이 적용되어야 한다면 별도의 서비스로 추출해서 트랜잭션을 적용하자. 학습 회고Presentation에서 검증의 책임을 어느정도까지 가져야 하는지, Mock을 어떤 시점에 적용해야 하는지 명확하게 알게 되어서 좋았다. 그리고 섹션 8에서는 더 나은 테스트를 작성하기 위한 구체적인 조언을 해주셨는데, 여기서 환경을 통합해야 한다는 내용이 공감이 많이 갔다. 기존에 했던 팀 프로젝트에서 테스트가 많아지면서 실행 시간이 계속 늘어났는데 환경을 통합해서 시간을 줄이는 것을 적용해야겠다. 미션Day 15: Layered Architecture 구조의 레이어는 어떤 특징이 있고 어떻게 테스트하면 좋을지https://gist.github.com/hlmg/f52fe2f82c34f5c3a27459300d18a8b1Day 18: @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이https://gist.github.com/hlmg/6ad50efae29b9f33925f8fcd293f3031 미션 회고미션을 풀면서 각 레이어가 어떤 특징을 가지고 있는지 그리고 어떻게 테스트할지 다시 한 번 정리할 수 있었다. 헷갈리는 Mock관련 Annotation 들을 정리하면서 단위 테스트에는 어떤 것들을 사용하고 통합 테스트에는 어떤 걸 사용해야하는 지 명확하게 알게되어서 좋았다.

dd 25일 전
sodee

[인프런 워밍업 클럽 스터디 2기] 프로덕트 디자인 4주차 발자국

1. 이번 주에 공부한 것B2C 이러닝 페이지 만들기모바일 OTT 서비스 페이지 만들기타이포그래피 배리어블 등록하기 2. 이번 주 학습에서 느낀점이러닝 페이지에서 카드 on/off 만드는게 안 되어서 많이 힘들었다. 나름 공식 가이드를 찾아보다가 안 되어서 볼드님께 여쭈었는데, 그 외에 디스코드에서 다른 분이 커뮤니티를 찾아보면서 문제점을 파악하는 방식도 있다는 걸 알게 되었다. 좋은 방법을 배웠다 🙂  3. 잘한 점마무리를 잘한 것?! 과제도 무사히 제출했고, 특강도 참여했고(개인적인 문제로 실습을 할 수 없었지만) 오늘 이렇게 발자국도 쓰고 있다. 4. 아쉬운점이번주는 없음.. 😁 5. 후기피그마 배리어블은 해야지 해야지 하면서 미뤄놓고 있었는데 이번 기회를 통해서 완강하게 되어서 너무 행복하다. 워밍업 클럽 덕분에 학습도 하고, 추가 특강을 들으면서 다양한 활용법도 배워서 정말 참여하길 잘했다,라는 생각이 드는 시간이였다. 특히 반응형을 잘 못해 고민을 느꼈는데 이번 클럽을 통해 극복할 수 있었고, 강의를 듣고 난 후 프론트엔드 쪽도 조금씩 보고 있는데 신기하게도 이전보다 이해도가 올라간 느낌이였다. 정말 많이 배웠습니다!!

피그마디자인시스템

김진수

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

인프런 워밍업 클럽 2기 발자국 4주차1. 한 주의 정리드디어 마지막 주차이다. 이번 주차는 Layerd Architecture에서 Presentation Layer와Test Double 그리고 테스트를 작성하기 위한 팁들, 마지막으로 부록이 있다. 마지막 페이즈답게 테스트를 위한 지식공유자님의 개인적인 견해와 팁들이 많이 녹아져 있는 강의들이라 좋았다. ✅ 섹션 6. Presentation Layer Test표현 계층에 대한 테스트를 작성하는 방법에 대해 배움,중요한 것은 비즈니스 로직이 들어가는 것이 아니라 넘겨온 값들에 대한 검증이라고 생각한다고 하더라,나 또한 동의한다. ✅ 섹션 7. Mock을 대하는 자세Test Double에 대해 배우고 각 객체의 사용법 그리고 지식공유자님의 개인적 견해가 들어가 있다. 처음으론 Stub과 Mock! 많이 헷갈렸는데Stub은 상태 검증Mock은 행위 검증이라는 관점에서 접근하는 방법을 배웠다. 다음은 Mock하면 항상 나오는 말인데, Classicist VS Mockist이다. 우선 나는 Classicist쪽에 더 가깝다. Mocking을 하면 항상 통과할텐데..(왜냐면 그렇게 짜여지니까)실제상황에서의 다양한 변인들을 통제할 수 있을까? 하는 생각이다. 그렇지만 완고한 고전파는 아니고 Mocking하고 넘어가도 되는 부분은 충분히 그럴 수 있다는 생각이다. ✅ 섹션 8. 더 나은 테스트를 작성하기 위한 구체적 조언완전 농축 액기스 섹션이다.지식공유자님께서 여지껏 겪어오면서 고민하고, 또 좋았던 경험을 바탕으로 팁들을 녹여놓은 섹션이다.다른 섹션들도 물론 군데군데 그것들이 녹여져있지만, 이 섹션에서는 아예 그냥 키워드를 퍼먹여준다.꼭꼭 씹고 내 것으로 만들자. ✅ 섹션 9. Appendix부록인데 부록이 아니다.우선 처음은 테스트 코드를 조금 친숙히 다가가는 법, 아닌 말로 뭐 만드는게 없는데 테스트코드를 어떻게 짜요? 란 생각이 은연 중에 있었다.그런 나의 썩은 정신 상태를 고쳐줄 수 있는 좋은 방법이었다. Spring REST Docs는 확실히 Swagger와는 다른 장점을 보인다.나는 Docs쪽을 더 선호하는 데 이 강의에서 말한 Swagger의 단점이 나는 아주 치명적으로 느껴져서이다. ✅ 섹션 10. Outro그 동안 학습했던 것들에 대한 정리와 조언..? 사람들은 매번 겪어야 깨닫는 특성이 있는데.나 또한 마찬가지고, 어찌됐든 테스트를 짜는게 느린게 아니라 빠른거다 라는 것은 점점 피부로 느껴진다. 흔히 나는 게임에 비유를 하는데 테스트 코드는 공략이다. 이 요구사항을 어떻게 해치울 지 공략이 있다면, 프로덕션 코드는 공략대로 가면 된다. 근데 공략이 없다면.. 좀 더 오래걸리더라 ..  2. 미션이번 주차에서는 Layerd Architecture 구조의 레이어 별 특징과 어떻게 테스트하면 좋을 지 그리고 @Mock, @MockBean, @Spy, @SpyBean, @InjectMock에 대한 정리와예시 테스트의 시나리오 재배치 2가지의 미션이 있었다. 하나하나 작성하기 양이 좀 되어 따로 블로그에 작성한 링크를 참조하려 한다. ✅ 미션 Day-15https://romanc3.tistory.com/131 ✅ 미션 Day-18https://romanc3.tistory.com/132 🤔 내 생각을 정리하자면강의도 좋았지만, 워밍업 클럽 자체가 좋은 기획 같다.동일한 관심사를 가진 사람들과 같은 강의를 보며 다른 생각을 경험할 수 있다는 점이 아주 좋았고,지식 공유자님과 면대면은 아니더라도 의견을 주고 받을 수 있는 공간을 제공 받을 수 있다는 것이 큰 이득으로 다가왔다. 잘하고 싶다면, 잘하는 사람을 모방 하라는 말이 있다.모방을 우습게 보는데.. 따라하기란 쉬운게 아니다. 결국 똑같이 따라할 수 있다는 것은 똑같은 실력이란 것이다.그러한 관점에서 나는 내가 생각하기에 좋은 개발자 분들을 많이 알 수 있게 된 기회였다. 언제까지나 테스트에 매몰되어 있지는 말고, 얼른 마무리해서 습관적으로 테스트를 작성하고 또 다른 부분을 신경쓸 수 있는 개발자로 거듭나길 연습해야겠다 😃

백엔드백엔드테스트

suover

인프런 워밍업 클럽 스터디 2기 - 백엔드 프로젝트 4주차 발자국

입문자를 위한 Spring Boot with Kotlin - 나만의 포트폴리오 사이트 만들기강의와 함께한 인프런 워밍업 클럽 스터디 2기 - 백엔드 프로젝트 (Kotlin, Spring Boot) 4주차 발자국 입니다. 강의 수강이번 주에는 Spring Boot와 JPA를 사용한 뷰 개발 및 Thymeleaf를 활용한 프론트엔드 템플릿 작업에 중점을 두었습니다. 주로 Bootstrap 템플릿을 가져와 활용하고, Thymeleaf의 fragment 기능을 사용하여 재사용 가능한 HTML 구조를 만들었으며, 배포 작업까지 진행했습니다.주요 학습 내용Bootstrap 템플릿 가져오기 및 적용Bootstrapmade 사이트에서 Admin 템플릿을 다운로드하여 프로젝트에 적용했습니다.템플릿 파일을 프로젝트의 resources 디렉토리에 추가하고, 필요한 CSS, JS 파일들을 적용했습니다.Thymeleaf와 프론트엔드 분리 작업Thymeleaf의 fragment 기능을 활용해 HTML 구조를 모듈화하였습니다. head, header, footer 등 여러 공통 요소를 별도의 fragment로 분리하여 재사용성을 높였습니다.타임리프 문법을 통해 동적으로 페이지를 구성하고 유지보수가 용이하도록 개선했습니다.프로젝트 배포 작업Docker를 이용해 MySQL을 컨테이너로 실행하고, Spring Boot 애플리케이션을 Docker 이미지로 빌드하여 배포했습니다.Nginx를 사용해 80포트와 8080포트를 연결하여 클라이언트 요청을 처리하도록 설정했습니다.Let's Encrypt를 이용해 HTTPS 인증서를 설정하고, 웹사이트를 HTTPS로 안전하게 접근할 수 있도록 구성했습니다. 회고이번 주는 Thymeleaf와 Bootstrap을 활용하여 프론트엔드 작업을 진행하며, 뷰를 모듈화하고 효율적으로 구성하는 방법을 배울 수 있었습니다. 특히 Thymeleaf의 fragment 기능은 HTML 코드의 재사용성과 유지보수성을 크게 개선해 주어 프로젝트의 구조를 더욱 체계적으로 만들 수 있었습니다. 또한, 직접 템플릿을 가져와 수정하고 적용하는 과정을 통해 프론트엔드 개발 역량을 키울 수 있었고, Docker와 Nginx를 이용한 배포 작업을 통해 실제 서비스 환경에서의 배포 경험도 쌓을 수 있었습니다.칭찬할 점Thymeleaf를 사용하여 공통 레이아웃을 fragment로 분리하여 재사용성을 높인 점.Bootstrap 템플릿을 프로젝트에 무리 없이 적용하고, 필요한 수정 작업을 성공적으로 수행한 점.Docker와 Nginx를 이용한 배포 과정을 원활히 진행한 점.아쉬웠던 점 및 보완할 점Thymeleaf 문법에 대한 익숙함이 아직 부족하여 일부 동적 작업에서 어려움을 겪었습니다. 추가적인 연습과 학습을 통해 더 익숙해질 필요가 있습니다.프론트엔드 요소의 커스터마이징에 있어 부족함을 느꼈으며, 좀 더 세밀한 스타일 수정 방법을 연구하고자 합니다. 미션이번 주 미션은 삽입, 수정, 삭제 REST API를 개발하고, 이를 검증하는 테스트 코드를 작성하는 것이었습니다. API는 각 기능별로 POST, PUT, DELETE 요청을 처리하도록 설계하였으며, 모든 케이스에 대해 성공적으로 테스트를 완료했습니다.미션 과정게시글 삽입 API 설계 (POST /api/posts)새로운 게시글을 작성하고, 작성된 데이터를 JSON 형태로 반환하도록 설계했습니다.게시글 수정 API 설계 (PUT /api/posts/{postId})특정 게시글을 수정하고, 수정된 결과를 반환하는 기능을 구현했습니다.게시글 삭제 API 설계 (DELETE /api/posts/{postId})특정 게시글을 삭제하고, 삭제 후 상태 코드 204 No Content를 반환하도록 했습니다.테스트 코드 작성 및 검증각 엔드포인트에 대해 최소 3개의 테스트 케이스를 작성해, 다양한 상황에서의 시스템 동작을 검증했습니다.필수 값이 누락된 경우, 잘못된 ID로 요청했을 때의 예외 처리 등도 함께 테스트하여 안정성을 확보했습니다.  미션 과정추가적으로 가상 프로필을 나의 프로필로 바꾸기 미션과 배포한 프로젝트 공유하기 미션까지 모두 마무리하며, 스터디의 모든 미션을 마무리 하였습니다. 이 발자국을 끝으로 모든 미션과 발자국, 강의 수강 100% 까지 마무리 하며, 스터디를 성공적으로 완주하였습니다. 회고이번 미션을 통해 RESTful한 API 설계 및 테스트의 중요성을 다시 한번 체감할 수 있었습니다. 또한, Thymeleaf를 활용해 프론트엔드를 모듈화하고 코드의 재사용성을 높이는 작업이 실제 프로젝트에서 어떻게 활용될 수 있는지 직접 경험할 수 있는 시간이었습니다. 배포 작업을 통해 실제 서비스 환경에서 발생할 수 있는 문제들을 다루며, 더 나은 품질의 소프트웨어를 개발하기 위한 실무 경험을 쌓을 수 있었습니다. 앞으로 JPA 연관 관계에 대한 이해를 깊이 있게 다지고, 테스트 코드의 가독성을 더욱 높이는 방법을 연구하여 더 나은 품질의 소프트웨어를 개발해 나가겠습니다.

백엔드인프런워밍업클럽스터디백엔드프로젝트발자국회고SpringBoot

송준환

인프런 워밍업 클럽 2기 - BE 클린코드, 테스트코드 스터디 4주차 발자국

일주일 간 학습 내용 요약BDD와 TDD를 활용한 테스트 작성 원칙테스트는 문서다테스트 코드는 프로덕션 기능을 설명하는 문서 역할을 한다.다양한 테스트 케이스를 통해 프로덕션 코드를 이해하고, 팀 차원의 자산으로 공유할 수 있다. DisplayName을 섬세하게 작성테스트 이름은 명사 나열보다 문장 형식으로 작성해야 한다.테스트 행위의 결과까지 명확히 기술하며, 도메인 용어를 사용해 추상화된 내용을 담아야 한다.메서드 관점이 아닌 도메인 정책 관점에서 기술하는 것이 중요하다. BDD(Behavior Driven Development) BDD는 TDD에서 파생된 개발 방법론으로, 함수 단위 테스트보다는 시나리오에 기반한 테스트 케이스에 집중한다.개발자가 아닌 사람도 이해할 수 있는 수준의 추상화를 권장하며, “Given-When-Then” 구조로 작성된다.Given: 시나리오 진행을 위한 준비 과정.When: 시나리오 행동이 진행되는 단계.Then: 결과를 명시하고 검증하는 단계.  테스트 작성 팁현상을 중점으로 기술하기보다는 도메인 정책에 맞게 테스트를 작성한다.테스트는 단순한 검증이 아니라 프로덕션 코드의 발전을 돕는 중요한 문서로써 팀의 자산이 된다.Mocking의 원리Mock을 마주하는 자세Mocking은 테스트를 할 때 실제 객체 대신에 가짜 객체(Test Double)를 사용하여 객체 간의 상호작용을 검증하는 방법이다.특히, 외부 시스템과의 상호작용을 모방하여 시스템의 동작을 시뮬레이션한다. Test Double의 종류Dummy: 아무런 기능을 하지 않는 객체.Fake: 실제로는 사용하지 않지만, 간단한 기능을 제공하는 객체(ex. FakeRepository).Stub: 미리 준비된 결과를 제공하는 객체.Spy: Stub처럼 동작하나, 호출된 내용을 기록하여 검증할 수 있는 객체.Mock: 특정 행위에 대한 기대를 명세하고, 그에 따라 동작하도록 만들어진 객체. 상태 검증 대신 행위 검증(Behavior Verification)을 중심으로 한다. Classicist vs. MockistClassicist: 상태 검증을 중시하는 전통적인 테스트 방식.Mockist: 행위 검증을 중시하는 방식으로, 객체 간의 상호작용을 검증하는 데 집중한다. Spring에서의 Mocking@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks: Spring에서 사용되는 다양한 Mocking 어노테이션과 그 용도.BDDMockito: BDD 스타일로 Mocking을 지원하는 라이브러리. Layered Architecture에서의 MockingPersistence Layer, Business Layer, Presentation Layer 각각에 대한 Mocking을 적용할 수 있으며, 통합 테스트보다 더 작은 단위의 테스트를 위한 도구로 사용된다.더 나은 테스트 작성 방법테스트 작성 원칙테스트 하나 당 목적은 하나: 테스트는 명확한 목표를 가지고 하나의 기능만을 검증해야 한다.완벽한 제어: 테스트에서 모든 상황을 완벽히 제어하고, 외부 의존성 없이 독립적으로 실행될 수 있어야 한다.테스트 환경의 독립성: 테스트 환경은 독립적으로 설정되어야 하며, 다른 테스트에 영향을 미치지 않아야 한다.테스트 간 독립성: 각 테스트는 서로 영향을 주지 않도록 독립성을 보장해야 한다. Test FixtureTest Fixture란 테스트를 위해 준비된 고정된 상태의 객체 집합을 의미하며, 테스트가 실행될 때 필요한 환경을 설정해 준다.Fixture 클렌징: 테스트 후 Test Fixture를 적절하게 정리하고 초기화해야 한다. 테스트 수행과 비용테스트를 수행하는 것도 비용이므로 가능한 한 테스트 환경을 통합하고 효율적으로 구성해야 한다. ParameterizedTest와 DynamicTest@ParameterizedTest: 여러 입력값에 대해 동일한 테스트를 반복할 때 사용한다.@DynamicTest: 동적으로 테스트 케이스를 생성하여 실행할 수 있다.효과적인 테스트 기반 API 문서화학습 테스트새로운 기능, 라이브러리, 프레임워크 등을 학습하기 위해 작성하는 테스트.여러 테스트 케이스를 정의하고 검증하는 과정을 통해 해당 기술의 동작과 기능을 더 깊이 이해할 수 있다.관련 문서를 읽는 것보다 재미있고, 실질적인 학습 방법으로 사용된다. Spring REST DocsAPI 명세를 자동으로 문서화해주는 도구로, 테스트 코드를 기반으로 API 문서를 생성한다.문서화된 API 명세는 협업을 원활하게 하며, 테스트가 통과해야 문서가 생성되므로 신뢰도가 높다.기본적으로 AsciiDoc을 사용하여 문서를 작성한다. REST Docs vs. SwaggerSpring REST Docs테스트를 통과해야 문서가 생성되기 때문에 신뢰도가 높다.프로덕션 코드에 영향을 주지 않지만 설정이 복잡하고 코드 양이 많다는 단점이 있다.Swagger설정이 쉽고, 문서에서 바로 API를 호출할 수 있는 기능을 제공한다.그러나 프로덕션 코드에 영향을 미치고, 테스트와 무관하게 문서가 생성되기 때문에 신뢰도가 떨어질 수 있다.회고• 칭찬하고 싶은 점: 시간이 많이 없었지만 미션과 발자국 모두 기한안에 낼 수 있어서 좋았다.• 아쉬웠던 점: 미션 제출 기한에 쫓겨 강의를 서둘러 듣고 제출한 점은 살짝 아쉽다.• 보완하고 싶은 점: 배운 내용들을 다시한번 복습해봐야겠다.드디어 마지막주까지 학습을 마치고 스터디가 끝났다. 4주동안 정말 많은 도움이 됐다. 클린코드와 테스트코드 모두 어느정도 틀과 방향성을 잡았으니 이제 시작이라고 생각한다. 항상 배운 내용들을 생각하고 돌려보며 코드를 작성하는 습관을 들여야겠다.Day 18 미션https://wnsghks.notion.site/Day-18-12a172cf6ea18016bb2bd5742b720bfc?pvs=4참고강의박우빈 - Readable Code: 읽기 좋은 코드를 작성하는 사고법

인프런워밍업클럽클린코드스터디테스트코드스터디

송준환

인프런 워밍업 클럽 2기 - BE 클린코드, 테스트코드 스터디 2주차 발자국

일주일 간 학습 내용 요약코드 다듬기주석의 양면성주석이 많다는 것은 코드가 비즈니스 요구사항을 잘 반영하지 못했다는 의미일 수 있다. 주석에 의존하면 코드 품질이 떨어질 수 있다. 주석은 코드로 설명할 수 없는 의사 결정 히스토리를 설명하는 데 사용하며, 자주 변하지 않는 정보를 기록해야 한다. 변수와 메서드의 나열 순서변수는 사용하는 순서대로 나열하고, 메서드는 공개 메서드를 상단에 배치하는 것이 일반적이다. 공개 메서드는 중요도나 종류별로 그룹화하여 나열하고, 비공개 메서드는 공개 메서드에서 언급된 순서대로 배치한다. 패키지 나누기패키지는 문맥에 따라 나누어 관리해야 하며, 너무 잘게 쪼개거나 너무 크게 묶지 않도록 주의한다. 대규모 패키지 변경은 팀원과의 합의가 필요하다. 기능 유지보수버그 수정과 알고리즘 교체는 코드 유지보수에서 중요한 부분이다. 예를 들어, DFS와 BFS 알고리즘 교체 시 재귀 대신 스택을 사용하는 방식으로 변경할 수 있다. IDE 도움 받기코드 정렬 및 품질 체크 도구(linting) 사용이 중요하다. 협업 시에는 팀 내 합의된 포맷을 따르고, 정해진 스타일을 지속적으로 개선하는 것이 필요하다.기억하기 좋은 조언들능동적 읽기복잡하거나 난해한 코드를 읽을 때는 리팩토링하면서 읽는 것이 좋다. 목표는 도메인 지식을 확장하고 이전 작성자의 의도를 파악하는 것이다. 주석을 사용해 이해한 내용을 기록하며 읽는 것도 도움이 된다. 오버 엔지니어링필요한 수준 이상으로 복잡한 구조를 만드는 것은 피해야 한다. 예를 들어, 구현체가 하나인 인터페이스는 아키텍처 이해에 도움을 주거나, 곧 추가될 가능성이 있을 때만 유용하다. 너무 이른 추상화는 오히려 복잡도를 높이고 이해를 어렵게 만든다. 은탄환은 없다모든 문제를 해결해주는 만능 해결책(은탄환)은 존재하지 않는다. 클린 코드도 상황에 따라 적정한 수준에서 적용해야 하며, 실무에서는 소프트웨어의 품질과 빠른 결과물 사이에서 균형을 맞춰야 한다. 적정 수준을 파악하기 위해서는 극단적인 시도를 해보는 것이 중요하다.회고• 칭찬하고 싶은 점: 이해가 되지 않는 것들은 이해가 될때까지 여러번 돌려보니 어느정도 감이 잡혀가고 있다. 앞으로도 시간이 조금 더 걸리더라도 이해하고 넘어가는게 좋을 것 같다.• 아쉬웠던 점: 분명 강의를 들을땐 아 그렇지 하고 넘어갔는데 막상 리팩토링 미션을 마주하니 뭐부터 해야될지 감이 안잡혔다. 뭘 해야겠다는 생각은 머릿속에 있는데 어디부터 어떻게 시작할지 고민이 많았다. 아직 배우기만 했지 실제로 코드를 직접 치는일은 많이 없어서 경험이 진짜 중요하다는것을 느꼈다.• 보완하고 싶은 점: 일단 코드를 많이 작성해봐야 내것으로 만들 수 있을 것 같다. 무조건 직접 코드를 쳐보자.다음 주 학습 목표• 다음주 부터는 테스트 코드 강의가 있는데 놓치는 일이 없도록 초반부터 완벽히 학습해야 할 것 같다.Day 7 미션https://github.com/junhwan98/readable-code-mission/tree/main/day7/tobe참고강의박우빈 - Readable Code: 읽기 좋은 코드를 작성하는 사고법

송준환

인프런 워밍업 클럽 2기 - BE 클린코드, 테스트코드 스터디 3주차 발자국

일주일 간 학습 내용 요약테스트를 해야하는 이유테스트는 귀찮지만 필수적이다테스트를 하지 않으면 경험과 감에 의존해 개발하게 되고, 커버할 수 없는 영역이 발생하며 유지보수가 어려워진다. 결과적으로 소프트웨어에 대한 신뢰가 떨어지고 피드백이 늦어질 수 있다. 테스트의 목적빠른 피드백을 제공하고, 자동화로 안정감을 얻는 것이 목표다. 매 순간 소프트웨어의 변화가 발생할 때마다 모든 경우를 고려하고 팀원이 동일한 고민을 해야 한다. 테스트 코드를 작성하지 않으면소프트웨어의 안정성을 보장할 수 없다.반대로, 테스트 코드가 병목 현상을 일으키면 유지보수가 어렵고, 잘못된 검증이 이루어질 가능성도 있다. 올바른 테스트 코드의 장점자동화 테스트를 통해 빠르게 버그를 발견할 수 있고, 수동 테스트 비용을 절약한다.빠르게 변화하는 소프트웨어를 지원하며 팀의 집단 지성을 이익으로 승격시킨다. 초기에는 느려 보일 수 있지만, 장기적으로는 가장 빠른 방법이다.테스트 주도 개발(TDD)TDD(Test Driven Development)TDD는 테스트 코드를 먼저 작성하고, 그 테스트를 통과하기 위해 프로덕션 코드를 작성하는 개발 방법론이다. 테스트가 구현 과정을 주도하게 되며, 기능 테스트와 구현 순서에 따라 진행된다. RED-GREEN-REFACTOR 주기RED: 실패하는 테스트를 작성한다. GREEN: 테스트를 통과하기 위한 최소한의 코딩을 한다. REFACTOR: 코드를 개선하면서 테스트가 통과되도록 유지한다. TDD의 이점복잡도가 낮고 테스트 가능한 코드로 구현할 수 있으며, 엣지 케이스를 놓치지 않도록 한다. 빠른 피드백을 받아 유연하고 유지보수가 쉬운 코드를 작성할 수 있고, 과감한 리팩토링도 가능하게 한다. 관점의 변화전통적으로 테스트는 구현부 검증을 위한 보조 수단으로 여겨졌지만, TDD에서는 테스트와 구현부가 상호작용하며 발전하는 형태로 변화한다. 클라이언트 관점에서 피드백을 받는 방식으로 발전한다.회고• 칭찬하고 싶은 점: 테스트코드에 대해 궁금점이 많이 있었는데 강의를 듣고 어느정도 많이 해소됐다.• 아쉬웠던 점: 생각보다 시간이 많이걸려서 서둘러 미션을 제출한것이 살짝 아쉬웠다.• 보완하고 싶은 점: 시간을 넉넉하게 잡고 미션을 수행해야겠다.다음 주 학습 목표• 강의를 완벽히 내것으로 만들고 나머지 미션까지 기한 내에 제출하면 좋을 것 같다.Day 12 미션https://github.com/junhwan98/readable-code/tree/main/src/test/java/cleancode/studycafe/tobe참고강의박우빈 - Readable Code: 읽기 좋은 코드를 작성하는 사고법

테스트코드

채널톡 아이콘