인프런 워밍업 클럽 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주차라니 시간이 어떻게 흘러간지 모르겠다. 이번 주는 특히나 내가 평소 궁금했던 것들에 대한 강의여서 더 집중해서 들었던 것 같다. 바로 프로젝트에 적용 해볼 만 한 내용이 많아서 만족스러웠다. 워밍업 클럽 진도를 따라가는게 쉽지는 않았지만 지나고 보니 포기하지 않고 어떻게든 하려고 노력 했던 것이 많은 도움이 된 것 같다.

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

강의 출처 Practical Testing: 실용적인 테스트 가이드 학습 내용단위 테스트JUnit5AssertJ(assertThat(actual).isEqualTo(expected)..)테스트 케이스 세분화 하기해피 케이스 (항상 통과하는 테스트)예외 케이스 -> 경계값 테스트 (범위, 구간, 날짜 등)테스트 하기 어려운 영역은 구분하고 분리해야 한다. (테스트 내부에 있는 값을 파라미터, 상수로 분리)현재 날짜/시간, 랜덤한 값, 전역변수/함수, 사용자 입력 등 표준 출력, 메시지 발송, db에 기록하기 등TDD : Test Driven Development프로덕션 코드보다 테스트 코드를 먼저 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론실패하는 테스트 작성(RED) -> 테스트를 통과하는 최소한의 코딩(GREEN) -> 구현 코드 리팩토링(REFACTOR)TDD의 핵심가치 - 피드백DisplayName문장 : A이면 B이다. / A이면 B가 아니고 C이다.테스트 행위에 대한 결과까지 기술도메인 용어를 사용하여 추상화 된 내용 담기테스트의 현상을 중점으로 기술 X특정 시간 이전에 주문을 생성하면 실패한다.(X)영업 시간 이전에는 주문을 생성할 수 없다.(O)BDD : Behavior Driven DevelopmentTDD에서 파생된 개발 방법Given : 시나리오 진행에 필요한 모든 준비 과정(객체, 값, 상태 등)When : 시나리오 행동 진행Then : 시나리오 진행에 대한 결과 명시, 검증 미션Readable Code 강의의 지뢰찾기 프로젝트로 단위 테스트 작성하는 미션. CellSnapshotTest(셀의 상태 - 빈 셀, 지뢰 셀, 숫자 셀, 열지 않은 셀), CellPositionTest(Cellposition 생성 - 해피 케이스, 0 미만의 인덱스 Cellposition 생성 불가 - 경계값 테스트), GameBoardTest(지뢰 셀을 오픈하면 게임상태 Lose로 변경), ConsoleInputHandlerTest(사용자가 1을 입력하면 셀 오픈). 총 3개의 테스트 클래스와 8개의 테스트를 작성했다. GameBoardTest와 ConsoleInputHandlerTest는 테스트에 실패 했는데, GameBoardTest의 경우는 검증하고자 하는 메소드에서 값을 제대로 불러오지 못하여 실패했다. ConsoleInputHandlerTest는 Scanner를 테스트 해야 했는데 NoSuchElementException이 발생해 테스트에 실패했다. 회고평소에 테스트에 대한 고민이 많았었는데, 강사님의 라이브 코딩으로 테스트 하는 법을 배울 수 있어서 좋았다. 무엇을, 어떻게 테스트 해야 하는지는 아직 어려움이 있어서 꾸준한 노력이 필요할 것 같다. 다음 주에는 강의 완강을 목표로 끝까지 최선을 다해야겠다.

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

강의 출처 Readable Code: 읽기 좋은 코드를 작성하는 사고법 학습 내용코드 다듬기주석 적절히 사용하기자주 변하는 정보는 지양관련 정책이나 코드가 변경될 경우 주석도 업데이트변수와 메서드의 나열 순서변수는 사용하는 순서대로 나열메서드의 경우 객체의 입장에서 고려공개 메서드를 상단에 배치공개 메서드끼리도 기준을 가지고 배치(상태변경 > 판별 >= 조회 메서드)비공개 메서드는 공개 메서드에서 언급된 순서대로 배치패키지 나누기문맥으로써 정보를 제공할 수 있음패키지를 쪼개지 않으면 관리가 어려움(너무 잘게 쪼개는 것도 관리가 어렵다)대규모 패키지 변경은 팀원과 합의 후기능 유지보수IDE의 도움받기코드품질 : sonarlint 포맷규칙 : .editorconfig 리팩토링메서드 추출로 추상화 레벨 맞추기중복 제거, 메서드 추출Optionalsetter 사용 x, 무분별한 getter사용 대신 객체에 메세지 보내기객체의 책임과 응집도IO 통합일급컬렉션 Order 객체 추출추상화 관점의 차이구현에 초점을 맞춘 추상화 / 도메인 개념에 초점을 맞춘 추상화미션사용자가 이용권을 선택하고 선택한 이용권에 따라서 가격을 계산하는 프로그램을 리팩토링하는 미션이었다. 추상화 레벨에 맞지 않는 부분이 있다면 메서드 추출 등으로 추상화 레벨을 맞춰주고, 객체지향 패러다임에 맞게 객체들이 상호 협력하고 있는지, SRP, DIP, 일급 컬렉션 등의 포인트로 리팩토링을 해주면 되었다.회고미션을 진행하는 동안 가장 큰 어려움은 전체 코드의 맥락을 파악하는 것이었다. 그러다보니 변수, 메서드명 변경, 메서드 추출 등의 소심한 리팩토링 위주로 미션을 진행했다. 수강했던 강의들의 복습의 필요성을 절실히 느낄 수 있었다. 지난 강의들을 바탕으로 읽기 좋은 코드란 무엇인지 끈임없이 고민하는 자세를 가져야겠다.

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

강의 출처 Readable Code: 읽기 좋은 코드를 작성하는 사고법 학습 내용읽기 좋은 코드를 작성하기 위해서는 추상화가 필요하다.추상화의 방법변수와 메서드의 이름에서 무엇을 하는지 알 수 있어야 한다.메서드 시그니처(메서드명, 파라미터), 반환타입추상화 레벨을 동등하게 해주어야 한다.상수 추출early return중첩 분기문, 중첩 반복문 줄이기부정어구를 대체 할 수 있는지예외처리(개발자가 의도한 예외와 예상치 못한 예외의 처리)NullPointException, Optional객체지향SOLID미션추상과 구체의 예시 : 카페에서 커피를 주문하는 것을 단계별로 구체화했다.코드 리팩토링 : 메서드명 변경, 메서드 추출, early return, 부정어구 대체 등을 하여 코드를 리팩토링 했다.SOLID 나만의 언어로 정리 회고클린코드에 대해 어떻게 접근해야 할 지 알 수 있어서 좋았다. 막연하게 어렵다고 생각했던 것들을 코드 리팩토링을 통해 공부할 수 있어서 좋았다. 그런데 생각보다 강의를 듣는게 빠듯했다. 강의만 듣는 것이 아니라 직접 코드로 적용해 보려고 하니까 강의 시간의 두 배는 더 소요되는 것 같다. 게다가 2번째 미션은 시간 안에 제출하지 못했기 때문에 다음 주부터는 시간 분배를 잘해야겠다.