BeforeEach 를 하위 클래스에서 다시 사용하는것에 대해서 질문 드립니다.

안녕하세요 jisu3316님 좋은 시도이신거 같습니다. Connection refused가 되는 이유로 짐작되는 부분은 하위 클래스의 setup과 상속한 ApiTest의 setup이 메소드 명이 같아서 override되면서 상위클래스의 setup을 실행시키지 않아서 그러는거 같습니다.하위클래스의 @BeforeEach의 메소드명을 상위클래스와 달리 해주시면 문제 없이 수행될거같습니다 ㅎㅎ

TRUNCATE TABLE 시 AUTO_INCREMENT 컬럼 1로 초기화

안녕하세요 pgrrr119 님!말씀해주신대로 MySQL에서 TRUNCATE TABLE을 할 경우 AUTO_INCREMENT 컬럼 값이 초기값으로 재설정되어 AUTO_INCREMENT를 1으로 다시 변경하는 쿼리를 실행할 필요가 없습니다.https://dev.mysql.com/doc/refman/8.0/en/truncate-table.htmlH2는 TRUNCATE TABLE을 실행하더라도 IDENTITY가 기본값으로 재설정되지 않습니다!https://www.h2database.com/html/commands.html#truncate_tableIDENTITY를 초기화 하기 위해서는 영상에서처럼 ALTER TABLE 'TABLE_NAME' ALTER COLUMN COLUMN_NAME RESTART WITH 1;또는 TRUNCATE TABLE 'TABLE_NAME' RESTART IDENTITY;와 같이 TRUNCATE TABLE 명령어 뒤에 RESTART IDENTITY를 추가해주시면 됩니다!실제로 ID를 1으로 재설정하는 쿼리를 주석처리하고 전체 테스트를 실행하면 테스트 격리가 안되서 테스트가 실패하는것을 확인하실 수 있습니다!

POJO로 개발 후 스프링으로 전환, 이후 JPA 전환하는 이유

안녕하세요 마운틴 님!POJO로 개발한 후 스프링으로 전환하고 마지막에 JPA로 전환하는 이유는 주로 설계 및 개발 과정에서의 효율성과 유연성 때문입니다. 처음부터 JPA로 개발하는 것도 가능하지만, 이렇게 접근할 경우 다음과 같은 단점이 있습니다.데이터 중심의 설계: JPA를 처음부터 사용하게 되면, 데이터 중심의 설계가 나오기 쉽습니다. 이로 인해 객체지향적인 설계 원칙이 무시되거나 희생될 수 있습니다. 반면, POJO를 먼저 사용하면 객체지향적인 설계 원칙에 충실한 코드를 작성할 수 있으며, 이후에 JPA로 전환하면서 객체와 데이터베이스 사이의 연동을 수월하게 할 수 있습니다.개발 시간: JPA를 처음부터 사용하면, 초기 개발 시간이 상대적으로 더 많이 소요됩니다. 반면에 POJO로 먼저 개발하면, 기능 구현에 집중하여 빠르게 개발할 수 있으며, 이후 스프링 및 JPA로 전환하면서 필요한 부분만 점진적으로 수정해 나갈 수 있습니다.따라서, POJO로 개발한 후 스프링과 JPA로 전환하는 접근 방식은 객체지향적인 설계 원칙을 준수하면서도 개발 시간을 줄이고 유연한 코드 작성이 가능한 방법입니다.

TestRestTemplate 대신에 RestAssured를 사용하는 이유가 있을까요?

안녕하세요 임요환 님 !영상에서 RestAssured를 사용한 이유에 대해서는 이전에 다른분께서 질문해주신 내용에 대한 답변과 비슷할거같아서 링크를 남겨드립니다!RestAssured를 사용하면 Spring의존성 없이 API요청을 테스트해볼 수 있어서 사용했습니다!감사합니다!

API 테스트로 전환하기

안녕하세요 enble_777 님!!영상에서 var 타입을 사용한건 상황에 따라 var타입을 사용하는게 타입을 명시하는거보다 가독성에 도움이 될 수 있다고 생각되어서 사용했습니다 !감사합니다!

코드 스타일에 대해서 질문드립니다.

안녕하세요 임요환 님!!우선 질문주셔서 감사합니다.1.변수에 final 키워드를 붙이는 이유는 변경이 필요 없는 변수를 불변으로 만들어서 코드의 안정성을 높이고, 변수의 값이 변경되는 오류를 방지하는 차원에서 값이 변경되지 않는 모든 변수를 불변으로 만듭니다.무분별하게 setter를 만들지 않는것과 비슷한 관점으로 이해해주시면 될거같습니다. 2.클래스에 public을 지우는 이유는 public은 어디서든 접근 가능하도록 허용하는 것이지만 package-private을 기본으로 함으로써 같은패키지 내에서만 접근 가능하도록 제한하여, 접근 범위를 더 명확하게 표현 할 수 있기 때문입니다. 테스트 클래스의 public을 지우는것이라면 public일 필요가 없기 때문에 지우는 것입니다! 3.메서드를 static으로 선언하는 이유는 Steps를 말씀하시는것으로 이해가 되는데요, static 메소드를 사용함으로써 인스턴스 생성없이 바로 호출하기 위해서 static으로 메소드를 선언했습니다.

ApiTest에서 MockMvc를 사용한 테스트가 아닌

안녕하세요 김동호님 ! 답변이 늦어서 죄송합니다.예제에서는 각 도메인별 API를 요청하는 Steps라는 클래스를 만들어서해당 객체로 API요청을 하고 있습니다. Steps 객체는 Spring 의존성이 없이 API 요청을 보내 볼 수 있습니다.mockMvc를 사용하기 위해서는 Steps가 mockMvc의존성을 주입받거나 해서 사용해야 될것 같은데요!그래서 좀 더 간단하게 재사용 하기 위해 RestAssured를 사용했습니다.감사합니다!

port와 adapter에 대해

안녕하세요 Minkyu Ha님!이번 강의에서 사용된 port와 adapter는 헥사고날 아키텍처, 포트 & 어댑터 등으로 불리고 있는 구조에서 말하는 아웃바운드 포트, 아웃바운드 어댑터라고 이해하시면 될거같습니다. 아웃바운드 포트를 이용해 애플리케이션 코어를 외부(DB, API, 등...)와 분리하여,애플리케이션 코어를 쉽게 테스트 하고, 외부의 변경으로 부터 코어를 보호하려는 의도로 사용했습니다.

.ast

안녕하세요 하하하님!테스트에서 .ast로 assertThat을 생성하는것은IDE를 추가로 설정해야 하는데요!제가 영상에서 사용한 단축키와 툴 사용법은영상 마지막에 [리뷰반영]이라는 영상에 모아놨습니다!.ast의 설정 방법은 아래와같습니다!(사진)Before: $EXPR$.astAfter: assertThat($EXPR$).isEqualTo("");정정합니다.(사진)+버튼아이콘을 클릭하신 뒤 Java를 선택해주시고(사진)org.assertj.core.api.Assertions.assertThat($EXPR$).isEqualTo("$END$");use static import possible을 체크해주시면 됩니다! 감사합니다! 😊

API 테스트로 전환하기 영상에서..

안녕하세요 doxxx93님!예리하게 잘 캐치하셨군요!😆ApiTest를 extends하면서 SpringBootTest어노테이션을 지우는 이유는 이미 ApiTest클래스에 SpringBootTest가 붙어있기 때문입니다! 상속 이후에 에러가 나신다면 ApiTest에 SpringBootTest를 확인해주시기 바랍니다! 아무래도 제가 강의를 너무 빠르게 진행하다보니영상을 시청하시면서 놓치신 분들이 많으실거같은데요😭 질문 감사합니다!!😊