[글또] 라이브러리를 Mocking하는 이유

INDEX

1. 글을 작성하게 된 배경: 개발 프로세스에서 모킹의 필요성을 느끼다
2. 테스트 종류: 단위, 통합, 시스템테스트
3. Mocking이란?
4. Mocking의 목적
5. Mocking 방법
6. MSW
   - Service Worker란?
   - MSW 동작 원리
   - MSW를 적용하면 어떤 점이 좋을까?
7. 결론 & 마무리

배경: 모킹의 필요성을 느끼다

우리가 생각하는 이상적인 개발 프로세스는 기획을 하고,

백엔드(서버)개발이 완료되면 프론트엔드 개발을 하는 것이다.

그런데, 프로젝트를 진행하다 보면 그게 현실적으로 쉽지 않다는 걸 느낀다.

정해진 일정이 있다는 것과, 잦은 수정이 일어나기 때문인데

이는 굉장히 비효율적이라는 것을 알 수 있다.

 

나 또한 프로젝트를 진행하면서, 잦은 수정은 물론 일정이 밀린 경험이 여러번 있었다.

그런데, 서버가 완성되지 않아도 서비스를 테스트 해볼 수 있는 방법이 있다고 한다.

오늘 테스트에 대한 개념을 정리하고, 이걸 쉽게 할 수 있도록 도와주는 MSW에 대해 알아볼 예정이다.

테스트 종류: 단위, 통합, 시스템 테스트

테스트의 종류에는 여러가지가 있는데, 테스트 스케일에 따라 분류가 된다.

1. 단위 테스트: 작은 코드 단위 테스트이며, 코드 블록 단위로 테스트 할 수 있다.
2. 통합 테스트: 여러개의 컴포넌트를 테스트하거나 or 시스템 통합 기능을 검증하는 테스트다.
3. 시스템 테스트: 전체 시스템 기능과 성능에 대한 종합 평가를 하는 형태의 테스트이다.

테스트코드 작성과 관련된 부분은 "테스트 코드 작성에 대한 고찰" 이라는 제목으로, 따로 글을 작성한 적이 있다.

시간 되면 한 번 이것도 읽어보길 추천한다!

Mocking이란?

Mocking은 테스트 코드를 유연하게 작성하도록 하는 기술이다.

가짜 객체 활용해 의존성이 높은 객체에 대해서 혹은 외부 시스템에 대한 테스트 쉽게 할 수 있다.

그렇다면 이런 Mocking의 목적은 무엇일까?

Mocking의 목적

Mocking의 목적은 테스트 하고자 하는 코드블록에서 사용 되는 외부 의존성 제거하는 것이다.
그 이유는 실제 객체 대신 가짜 객체로 의존성을 분리시키기 때문인데,

이로써 오직 로직 개발에만 집중할 수 있다는 엄청난 장점이 있다.
그리고 무엇보다도, 애플리케이션의 정확도화 효율성이 증가한다.

Mocking 방법

Mocking을 할 수 있는 방법에는 두 가지 정도로 이야기 할 수 있는데,

우선 첫 번째, 필요한 데이터 상태에 내부 로직을 붙여서 직접 Mocking하는 방법.

그리고 별도의 Mocking 서버를 생성하는 방법이 있다.

 

하지만 이 두 방법 모두 비효율 이라는 단점이 존재하고 많은 문제가 있다는 점이다.

이를 해결하기 위해서는 실제 네트워크 수준에서 Mocking하는 것이 필요하고,
그래서 우리는 MSW를 사용하는 것이다.

 

이제 MSW가 무엇인지, 어떤 동작 원리로 돌아가는지 파악해보자.

MSW?

서버 네트워크 요청을 가로채 모의 응답을 보내주는 API Mocking 라이브러리

 

MSW가 이렇게 할 수 있는 이유는 바로 Service Worker 덕분이다.

Service Worker?

웹 어플리케이션의 메인스레드와 분리된 별도의 백그라운드 스레드에서 실행시킬 수 있는 기술

 

이 Service Worker를 통해서 애플리케이션 UI Block이

없어도 연산 처리 및 네트워크 요청 가로채기가 가능해진다.

 

주로 사용되는 곳은 대표적으로,

1. 백드라운드 동기화 기능을 구현할 때
2. 높은 비용 계산 처리할 때
3. Push Event를 보낼때

이렇게 3가지가 있는데 반면 유의사항도 존재한다.

• IE 브라우저 지원 안된다는 점
• HTTPS프로토콜 환경이어야 테스트 가능하다는 점

이 두 가지를 유의해야한다.

MSW 동작 원리

MSW에서 Service Worker 설치를 한다. 그 다음 클라이언트가 요청을 보냈을 때,

그 요청을 복사하고 MSW는 해당 요청과 일치하는 응답을 생성한다.

그럼 서버를 통해 모의 작성된 응답이 제공되고, 이 응답은 클라이언트로 확인할 수 있게 되는 원리다.

MSW를 활용한 개발 방식의 장점

- TDD를 통해 버그를 조기 발견, 품질을 향상시킬 수 있다.

- API 없이도 프론트엔드 개발자는 기획자와 미리 프론트엔드 애플리케이션을 확인하며 피드백을 주고받고, 그 사이 백엔드 개발자는 API 개발을 진행 가능하다.
→ 이후 백엔드 개발자가 API를 제공하면, 프론트엔드 개발자는 별다른 작업 없이 MSW를 스위치 오프만 하면 Production으로 배포할 수 있는 형태의 개발 과정을 통해 개발 진행 가능하다.

- MSW는 디버깅이 필요한 상황에서도 좋은 시너지를 만들어 낼 수 있다.
→ 기획자 등 다른 누군가에게 각 화면을 공유하고 피드백을 받아야 하는 상황이 발생했을 때에도, 서비스 로직의 수정 없이도 MSW를 통해 제공이 가능.

결론

라이브러리를 Mocking하는 이유는 여러가지 장점을 가지고 있으므로, 도입해보는 것을 추천한다!

필자도 다음주차에 모킹 라이브러리를 도입한 프로젝트를 소개하는 글을 작성할 예정이다.