목차
1. Mock과 Mockito
2. @CrossOrigin
3. 디버깅

---

---

1. Mock과 Mockito

1) Mock을 사용하는 이유

1. 외부 시스템에 의존하지 않고 자체 테스트를 실행할 수 있어야 하기 때문이다.

   네트워크나 데이터베이스가 연결이 안된다고 해서 UnitTest도 함께 실행이 불가능하면 안 되기 때문에 Mock을 사용한다.

2. 실제 데이터베이스를 사용하게 되면 테스트를 할 때마다 DB가 수정되기 때문에 민감한 정보가 포함되어 있는 DB의 보안을 위해 Mock을 사용한다.

3. 테스트 시간도 줄이면서 불필요한 리소스 소비를 막고 객체의 행동까지 테스트하는 개발자가 컨트롤 가능하기 때문이다.

---

2) Mock이란

• 모의 객체(Mock Object)란 주로 객체 지향 프로그래밍으로 개발한 프로그램을 테스트할 경우 테스트를 수행할 모듈과 연결되는 외부의 다른 서비스나 모듈들을 실제 사용하는 모듈을 사용하지 않고 실제의 모듈을 흉내내는 가짜 모듈을 작성하여 테스트의 효용성을 높이는 데 사용하는 객체이다. 사용자 인터페이스(UI)나 데이터베이스 테스트 등과 같이 자동화된 테스트를 수행하기 어려운 때 널리 사용된다.

• Mockito

  mock을 쉽게 만들고 mock의 행동을 정하는 stubbing, 정상적으로 작동하는지에 대한 verify 등 다양한 기능을 제공해주는 프레임워크

---

3) Mockito 사용법

1. Mockito 설정

• Mockito를 사용하려면 테스트 클래스 위에 @ExtendWith(MockitoExtension.class) annotation을 붙여줘야 한다.

2. Mock 생성

• @Mock

  @Mock으로 만든 mock 객체는 가짜 객체이며 그 안에 메소드를 호출해서 사용하려면 반드시 stubbing을 해야한다.

  만약 stubbing을 하지 않고 그냥 호출한다면 primitive type은 0, 참조형은 null을 반환한다.

• @Spy

  @Spy로 만든 mock 객체는 진짜 객체이며 메소드 실행 시 스터빙을 하지 않으면 기존 객체의 로직을 실행한 다음, 스터빙을 한 경우엔 스터빙 값을 리턴한다.

• @InjectMocks

  @InjectMocks은 DI를 @Mock이나 @Spy로 생성된 mock객체를 자동으로 주입해주는 어노테이션이다.

  @InjectMocks을 쓴 객체의 mock 객체를 주입 받을 수 있는 형태는 Constructor, Property Setter, Field Injection이 있다.

3. Stubbing

• Test stub은 테스트 중에 만들어진 호출에 대해 미리 준비된 답변을 제공하는 것.

  만들어진 mock 객체의 메소드를 실행했을 때 어떤 리턴 값을 리턴할지를 정의하는 것.

• Mockito에서의 stubbing

  Mockito는 when메서드를 이용해서 스터빙을 지원하고 있다.
  when에 스터빙할 메서드를 넣고 그 이후에 어떤 동작을 어떻게 제어할지를 메서드 체이닝 형태로 작성한다.
  스터빙 방법은 OngoingStubbing, Stubber를 쓰는 2가지 방법이 있다.

• OngoingStubbing메서드:
  when에 넣은 메서드의 리턴 값을 정의해주는 메서드이다.

  when({스터빙할 메서드}).{OngoingStubbing 메서드};

  • thenReturn: 스터빙한 메서드 호출 후 어떤 객체를 리턴할 건지 정의
  • thenThrow: 스터빙한 메서드 호출 후 어떤 Exception을 Throw할 건지 정의
  • thenAnswer: 스터빙한 메서드 호출 후 어떤 작업을 할지 custom하게 정의.
    그러나 굳이 thenAnswer를 사용하지 않고 thenReturn, thenThrow메서드 사용을 추천하고 있다.
  • thenCallRealMethod: 실제 메서드 호출

• Stubber메서드:
  when에 스터빙할 클래스를 넣고 그 후에 메서드를 호출한다.
  스터빙이 반드시 실행되어야 하는 경우 사용하는 메서드이기 때문이다.
  또한 리턴 타입이 void인 메서드 테스트가 가능하다.

  {Stubber 메서드}.when({스터빙할 클래스}).{스터빙할 메서드}

  • doReturn: 스터빙 메서드 호출 후 어떤 행동을 할 건지 정의
  • doThrow: 스터빙 메서드 호출 후 어떤 Exception을 throw할 건지 정의
  • doAnswer: 스터빙 메서드 호출 후 어떤 작업을 할지 custom하게 정의
  • doNothing: 스터빙 메서드 호출 후 어떤 행동도 하지 않게 정의
  • doCallRealMethod: 실제 메서드 호출

---

---

2. @CrossOrigin

1) Same-Origin Policy

• 내부에서 사용하는 api를 무단으로 사용하려는 외부에 대해서 출처가 다르면 사용하지 못하게 하는 정책
• 프로토컬, 도메인, 포트가 모두 같을 시 동일 출처 정책을 따른다.

2) CORS(Cross-Origin Resource Sharing)

• 웹페이지의 제한된 자원을 외부 도메인에서 접근을 허용해주는 메커니즘
• 서로 다른 도메인에서 리소스를 공유하는 방식
• Same-Origin Policy와 반대되는 개념이다.

3) @CrossOrigin annotation

• 기본값: 모든 도메인, 모든 요청방식에 대해 허용한다는 의미를 지닌다.
• origin 속성: 허용할 도메인을 명시한다.

---

---

3. 디버깅

1. Step Into

   메서드 안으로 들어가서 메서드를 한 줄씩 진행하는 방법

2. Step Over

   함수 내부로 들어가지 않고 바로 실행시키고 다음 라인으로 이동하는 방법

3. Force Step Into

   third party library 같은 step into로 진행이 안되는 메서드의 내부로 들어가기

4. Step Out

   현재 함수의 나머지 부분을 실행시키고 함수를 호출시킨 곳까지 되돌아가는 것.

5. Drop Frame

   step into로 들어오기 전의 frame으로 나가는 것.