Getter관해서

안녕하세요, 아아 님!보통 객체에서 데이터를 꺼내어 사용할 때 getter를 사용하죠.데이터를 꺼내야 하는 대표적인 경우 중 하나는, 데이터를 명시적으로 출력하는 경우입니다.예를 들어 콘솔에 데이터를 출력하거나, API 응답의 최종 단에서 데이터를 클라이언트에 반환하는 경우가 있겠습니다.또는 상황에 따라 A 객체에서 B 객체에서 데이터를 넘겨주어야 할 경우도 있을 수 있겠네요.요지는, 객체를 만들자마자 getter를 열어서 아무 곳에서나 데이터를 꺼내지 말자, 입니다. 객체가 데이터를 캡슐화하고, 적절한 가공의 책임을 가져 객체의 역할을 온전히 다 해낼 수 있도록요.도움이 되셨기를 바랍니다.감사합니다. 🙂

이름 바꾸기

안녕하세요, 정예빵 님!음, 글쎄요. for문 내의 i는 반복을 위해 0부터 순차적으로 증가하는 값이기 때문에, 잘 생각해보면 지뢰라는 의미와는 거리가 멉니다. (지뢰가 0부터 증가하는 것은 아니니까요.) 오히려 10이라는 숫자가 지뢰 개수 라는 의미에 더 부합하죠.도움이 되셨기를 바랍니다.감사합니다 🙂

stack 대신 queue 를 사용해 bfs 로 변경해도 되나요??

안녕하세요, ewgregerg c 님!네, 그럼요. 저는 설명의 편의를 위해 DFS를 선택했고요. 탐색 과정에 문제만 없다면 어떤 방법을 사용해도 괜찮습니다.감사합니다. 🙂

단위 테스트에 대한 질문 fake, h2

안녕하세요, yacheku 님! 1. 단위테스트할때 fake Repo를 커스텀하는 노력만 조금 들인다면 단위 테스트에대한 속도도 더빨라질거라 생각하는데 어떻게 생각하시나요?어떤 형태의 단위 테스트인지, 커스텀을 어떻게 하실지는 모르겠지만, 잘 작성된 단위 테스트는 이미 속도가 충분히 빠른 테스트 방식입니다 ㅎㅎ 더 빠르게 한다고 해서 크게 (체감할 정도로) 효용성이 있을 것 같지는 않아요 🙂 2. fake repo를 만들때 list, map, set 중에 저는 map을선택하였는데 혹시 어떤것을 사용하시는지?저는 FakeRepository 자체가 관리 포인트가 된다고 생각하기 때문에 애초에 선호하는 방법은 아닙니다만, 사용한다면 탐색 비용을 고려하여 map을 사용할 것 같네요. 3. 테스트 패키지 구조를 통합, 단위 라는 패키지를따로만들어서 넣는것보다alt + insert로 만들기 쉽게 같은공간에 단위,통합이 존재하게하면서 Test, IT 라는 네이밍으로 클래스를만들고있는데 ex) OrderServiceTest, OrderServiceIT 우빈님은 어떻게 통합과 단위 패키지구조를 설계하시는지 궁금합니다.단위와 통합인지에 따라 패키지를 구분하지는 않습니다. 패키지 구조 관점에서는 어떻게 테스트할 것인지 보다 무엇을 테스트하는지가 더 중요하기 때문에, 테스트 대상인 클래스 기준으로 자연스럽게 패키지를 잡고(프로덕션 코드의 패키지 구조를 그대로 따라가도록), 필요하다면 테스트 클래스 이름만 차이를 줄 것 같아요.도움이 되셨기를 바랍니다.감사합니다. 🙂

동시성 테스트와 데이터 초기화

안녕하세요, 조희제 님!말씀 주신 상황을 제가 글로만 보다보니 100% 이해하기는 어렵지만, 이미 문제와 원인 파악을 잘 해주신 것 같아요. BeforeEach로 접근하신 방법도 나쁘지는 않습니다만, 확인하신대로 멀티 스레드 테스팅 환경에서는 해당 테스트에 영향을 줄 수 있는 테스트 어노테이션을 제거하고 접근하는 것이 더 좋아 보입니다.감사합니다 🙂

인텔리제이 테마, 플러그인

안녕하세요, ryudb0 님!아래 인프런 AI 인턴이 제 다른 답변 링크와 함께 잘 정리해 주었네요 ㅎㅎ참고로 폰트는 D2 Coding 사용하고 있습니다.감사합니다. 🙂

동시성 문제 테스트 관련해서 질문드립니다.

안녕하세요, 김세희 님!말씀 주신 내용으로는 정확히 어떤 상황인지 다 알기가 어렵지만, 동시성 테스트에 대해서 제가 주로 접근하는 방법을 말씀드릴게요.보통은 Executor와 CountDownLatch 를 사용하여 많은 요청(100회 정도, 혹은 그 이상)을 만들어내고, 동시적인 요청이 발생할 때 문제가 생기는 상황을 연출합니다. (실행 순서를 제어하여 일부러 만드는 상황과는 다릅니다.)하지만 매번 이런 테스트를 자동화하여 수행하기에는 시간도 오래 걸릴 수 있고, 여러모로 부담이 되기도 해서, 이런 상황이면 현재 코드에서는 문제가 발생하는구나, 정도를 확인하는 용도로 사용합니다. 그리고 해당 테스트 코드는 비활성화 해 둡니다. (코드를 지우지 않고 비활성화 하는 이유는, 다음에도 저나 다른 누군가가 참고하고 활용할 수 있게 하기 위함입니다.)실행 순서를 제어하는 방법을 사용할 수 있는 상황이라면 자동화할 수도 있고 가장 좋은 접근이겠지만, 보통은 동시성 문제가 생기는 상황을 의도적으로 구성하기 어려운 경우가 많은데요.그렇기에 위와 같이 다건의 요청을 발생시키는 임시 테스트로 확인하시는 것이 그나마 접근하기 용이한 방법일 것 같습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂

Mockito로 Stubbing하기 8분경 OrderRepository 테스트

안녕하세요, addvd 님! 1. createProduct는 대부분의 테스트 클래스에서 사용되는데 하나의 static 클래스와 같이 외부로 분리하는게 좋지 않을까 라는 생각을 해봤습니다.강의 중에도 말씀드리겠지만, 물론 그렇게도 할 수 있는데요. test fixture 생성 로직을 통합하여 관리할 경우, 프로젝트의 복잡도가 높아짐에 따라 또다른 관리 대상이 될 수 있습니다. (조금 다르게 kotlin에서는, 메서드에 파라미터명을 지정(named arguments)할 수 있기 때문에 보다 깔끔한 공통 fixture 클래스를 만들 수 있긴 합니다.) 2. 저는 Order 클래스의 상태 변경을 위해서 updateOrderStatus라는 메소드를 생성 하였는데 (아직 해당 강의를 끝까지는 보지 않고 강의를 보기전에 먼저 테스트 코드를 작성 해보고 있습니다) 이런 식으로 테스트를 위해서 메소드를 생성 하는 경우도 괜찮을까요?요것도 뒤쪽 강의에서 말씀 드리겠지만, 테스트를 위한 메서드는 최대한 지양해야 합니다.그래서 Order 테스트의 경우 Order.create()라는 메서드를 사용하는 대신, 직접 status를 지정할 수 있는 Builder를 사용하여 Order를 생성하는 것이 좋습니다. 3. 제가 작성한 코드의 given 절이 너무 길어지는 느낌을 받았습니다. 현재는 order와 product를 생성 하는 정도이지만 더 복잡한 로직을 생성 할 경우 given이 너무 길어 지는것에 대한 해결 방안이 있을까요?일단 상위 레이어의 테스트일수록, 복잡도가 높을 수록 given절이 길어지는 것은 자연스럽습니다. 상황에 맞게 메서드를 분리하고, 테스트 케이스에 간접적인 영향을 미치는 준비 과정은 BeforeEach를 사용하는 등 여러 방법을 사용해볼 수 있겠습니다. (이것도 뒤쪽 강의에 말씀드려요.)도움이 되셨기를 바랍니다.감사합니다. 🙂

테스트 환경 통합하기 질문 있습니다.

안녕하세요, eoyeong 님!네, (mockBean 주입 등으로 인해) 그에 따라 스프링 컨텍스트가 달라지게 되니, 스프링 서버 자체가 새로 시작되게 됩니다. 그래서 전체 테스팅 시간을 단축시키기 위해 통합 환경을 구축하는 내용을 말씀드린 것이었어요.감사합니다. 🙂

하위 레이어가 상위 레이어를 알고 있는 경우에 대해 질문 있습니다.

안녕하세요, eoyeong 님!정확히는, 도메인 엔티티를 Infrastructure layer에서 알고 있다는 것이 문제가 아니라, 의존성 방향이 잘 설정되었는지가 주요한 내용입니다.말씀하신 구조는 서비스에서 인프라 레이어의 로직을 알지 못하고, 인터페이스를 통해 참조하는 형태이기 때문에 DIP가 잘 적용되어 있는 구조인데요.이 때, 인프라 레이어에서 도메인 엔티티를 알고 반환하는 것은 자연스러운 현상입니다. 의존성 방향은 이미 상위 레이어가 하위 레이어에 의존하지 않도록 역전되어 있는 상태이기 때문에 DIP를 위반하는 형태가 아닙니다.도움이 되셨기를 바랍니다.감사합니다. 🙂