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.html H2는 TRUNCATE TABLE을 실행하더라도 IDENTITY가 기본값으로 재설정되지 않습니다! https://www.h2database.com/html/commands.html#truncate_table IDENTITY를 초기화 하기 위해서는 영상에서처럼 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타입을 사용하는게 타입을 명시하는거보다 가독성에 도움이 될 수 있다고 생각되어서 사용했습니다 ! 감사합니다!