단위테스트와 통합테스트의 경계가 궁금합니다.

안녕하세요, rlamw2000 님!네, 맞습니다. 저는 통합 테스트란 어떤 계층부터 어떤 계층까지 테스트하는 것이다, 라고 정의하기 보다는, 둘 이상의 모듈을 묶어서 테스트하면 통합 테스트라고 생각하고 있어요.그래서 컨트롤러부터 리포지토리까지 전부 테스트하는 것도 마찬가지로 통합 테스트라고 생각합니다.단위 테스트는 독립적인지가 가장 중요한데요, 사실 그래서 강의에서 보여드린 컨트롤러 테스트와 리포지토리 테스트는 스프링을 띄워서 테스트하는 관점으로 보았을 때 엄밀히 통합 테스트겠지만, 서비스 레이어의 통합 테스트와 비교하였을 때 다른 계층이 관여하지 않는 다는 의미에서 "단위 테스트 느낌이 나는" 테스트라고 설명 드렸습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

Service+Repository 통합테스트 관련 질문입니다.

안녕하세요, hwang99 님! 1. 계층별 테스트 분리 기준에 대한 질문입니다.컨트롤러, 레포지토리는 단위테스트, 서비스 계층은 레포지토리 부분과 통합테스트 이렇게 분리해서 진행하셨던 이유를 여쭤봐도 될까요?2가지 관점일 것 같은데요. 첫 번째로 서비스 단위테스트를 하지 않았던 이유는, 말씀하신 것처럼 FakeRepository를 구성하는 리소스 대비 효과가 적다고 생각하기 때문입니다.두 번째로 서비스 레이어에서 통합 테스트를 진행한 이유는, 비즈니스 로직은 서비스 레이어부터 시작하기 때문입니다. 컨트롤러는 사실 (현재 구조에서는) 얇은 층이고, 담당한 역할이 외부 세계와의 소통, 최소한의 데이터 신뢰도 보장 정도이기 때문에 단위 테스트로도 충분하다고 생각해요.물론 여기에 더해 모든 층을 아울러서 테스트하는 통합 테스트, 더 나아가 인수 테스트도 할 수만 있다면 좋은 것이고, 복잡한 사용자 시나리오일수록 꼭 필요한 상황도 있다고 생각합니다. 2. 통합테스트 DB 관련 질문입니다.서비스계층과 레포지토리 계층을 묶은 상태로 H2 같은 임베디드 데이터베이스를 사용하면 테스트 속도가 상당히 느리게 나오긴 합니다. 이런 부분은 어쩔 수 없이 안고 가는 것인가요? 그리고 운영이나 개발 DB를 postgress같이 H2말고 다른 걸 사용한다고 해도, H2로 통합테스트 테스트하는게 이점이 있을까요?만약 항상 구동 중인 개발 DB에 테스트할 수 있다면 속도는 빠르겠으나, 여러 사람이 테스트할 경우 그 독립성을 보장해줄 수 있는 환경이어야만 할 것입니다.시간과 공간의 제약을 고려하고 독립성을 보장하면서, 그나마 빠른 인메모리 데이터베이스로 H2가 가장 적당하다고 생각합니다.물론 운영 DB와 H2와의 차이점 때문에 테스트가 어려운 케이스도 가끔 있습니다만 (ex. 스키마 차이) 그런 경우는 트레이드 오프로 감안하거나, 꼭 필요한 테스트 케이스라면 해당 케이스만 실제 운영 DB와 같은 종류의 DB를 구축하여 테스트하는 방식도 있겠습니다. 3. 서비스 계층 단위테스트 관련 질문입니다.혹시, 부담이 안 된다면, 서비스 계층의 단위테스트가 중요도가 많이 떨어진다고 생각하시는 이유가 Fake든 Mockito를 사용한 Stub이든 데이터베이스를 흉내만 내는 테스트가 의미가 없다고 여기셔서 그런 것일까요?저는 FakeRepository가 존재하는 프로젝트를 다룰 때, 매번 Repository 메서드를 하나씩 추가할 때마다 FakeRepository도 유지보수를 해야 해서 힘들었던 경험이 있는데요. 테스트만을 위한 코드를 작성한다는 느낌을 지울 수가 없었습니다 ㅎㅎ물론 서비스 계층의 단위 테스트를 할 수 있다는 장점이 있겠지만, 제가 느끼기에는 FakeRepsitory를 관리하는 만큼의 효용은 없었던 것 같아요.도움이 되셨기를 바랍니다.감사합니다. 🙂

OrderControllerDocsTest 작성 해봤는데요. 날짜 형식이 이상하게 나와요

안녕하세요, ewgregerg c 님!AI 인턴이 잘 설명해준 것처럼, LocalDateTime의 직렬화 문제인데요. 설명에 나와있는대로 ObjectMapper의 설정을 해주시면 해소가 될 것으로 보입니다.감사합니다. 🙂

test 용 .yml

안녕하세요, highjune 님!예시 프로젝트는 크기가 작기 때문에 별도 분리를 하지 않았는데요. 프로젝트가 복잡해짐에 따라 테스트 코드의 설정 파일을 별도로 두는 방법도 좋습니다. 다만, 프로덕션에서 사용하는 설정이 변하는 경우 같이 관리를 해주어야 한다는 단점이 있기 때문에 상황에 따라 잘 선택하시면 될 것 같아요.감사합니다. 🙂

throws Exception

안녕하세요, highjune 님!AI 인턴이 설명을 잘 해주었는데요, 테스트 코드에서는 테스팅하고자 하는 대상과 행위가 무엇인지에 따라 선택과 집중을 하는 것이 좋습니다. throws Exception으로 처리한 테스트 코드는 예외의 종류 자체가 중요한 테스트 케이스는 아니었을 것이고, 만약 테스트 코드가 checked exception에 대한 테스트를 하는 케이스였다면, 그에 대해 처리를 했을 것입니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

카페키오스크 클래스 문의 ,,

안녕하세요, itboxer91 님!앞 부분 강의를 살펴보시면 add() 메서드가 2개인 것을 확인하실 수 있습니다.감사합니다. 🙂

Rest docs 문서용 테스트코드를 따로 작성해야 되나요?

안녕하세요, ewgregerg c 님!물론 상관은 없으나, 저는 따로 관리하는 것을 선호합니다.문서용 테스트는 그 특성상 길이가 길기도 하고, 테스트이긴 하나 문서를 생성하기 위한 작업이기 때문에 프로덕션의 기능 테스트를 하는 ControllerTest와는 구분해서 보아야 할 필요가 있습니다.기능 테스트는 기능 테스트끼리, 문서 테스트는 문서 테스트끼리 분리하여 관리하는 것이 향후 프로덕트가 커짐에 따라 다루는 데에 더 용이하지 않을까 싶어요.감사합니다. 🙂

테스트 코드에서 필요한 생성자

안녕하세요, highjune 님! 1. 테스트 코드에서만 필요한 생성자가 있다면, 그 생성자를 위해서 해당 객체나 엔티티에 생성자를 추가하는 과정이 옳은 것일까요?기본적으로 테스트 코드만을 위한 결정은 지양하되, 때에 따라 보수적으로 용이한 테스트를 위해 메서드를 추가하는 결정을 할 수도 있는데요.size()나 getter() 같이 테스트에서 필요한 기능적인 메서드라면 모르겠으나 생성자는 이미 존재하는 프로덕션 생성자를 사용하면 되지 않을까, 하는 생각이긴 합니다. 2. 모 회사에서는 @Builder 패턴은 무조건 restdocs 를 생성하는 경우에만(fixtures) 사용하라고 해서 프로덕션 코드에서는 무조건 생성자만 사용한 경우가 있었는데 @Builder 패턴의 사용 범위? 그런 것들은 어떻게 생각하시나요!? 강사님의 의견이 궁금합니다.만약 팀에서 그렇게 결정한 팀 컨벤션이 있고, 그에 맞는 합당한 이유가 있다면 지키면 되는데요. 저는 강의에서 보여드린 범위가 적당하다고 생각합니다. Builder 패턴으로 인스턴스를 생성할 때 가져갈 수 있는 효용이 크다고 생각하기 때문이에요.도움이 되셨기를 바랍니다.감사합니다. 🙂

tearDown 순서

안녕하세요, highjune 님!네, 맞습니다. FK 제약조건이 걸려있는 상태기 때문에 순서를 고려하여 지워야 합니다.감사합니다. 🙂

@Builder 생성자 private

안녕하세요, highjune 님!아래 추가질문에 남겨주신 것처럼 생성자를 직접 사용하는 것보다, Builder를 사용하게끔 하는 의도가 있다고 이해해주시면 될 것 같아요.즉, Builder를 사용했을 때의 이점을 가져가기 위함인데요.Builder를 사용하는 것의 가장 큰 장점은 같은 타입의 파라미터를 필드명 기반으로 매칭시키면서 인스턴스를 생성할 수 있다는 것입니다. (서로 다른 String 타입의 두 필드를 필드명을 확인하면서 지정) 최소한의 휴먼 에러를 방지하는 역할이죠.도움이 되셨기를 바랍니다.감사합니다. 🙂