refactor: 테스트 리팩토링

[moresoo]

#98 의 리뷰를 반영합니다

• refactor: script element mock 유틸 활용 d294d42
• refactor: SDK load 테스트에서 NamespaceNotAvailableError 에러 관련 검증을 하지 않는다 6ce9a1e

[vreality64]

mockScriptElement 라는 이름이 document.createElement 를 mocking 한다는걸 드러내는게 아닐까요?
그래서 이 함수 내부에서 아래 로직도 함께 처리해줄거라고 기대할 것 같아요~

vi.spyOn(document, 'createElement')
  .mockReturnValueOnce(script)

그리고 eventListeners 는 없애도 되지 않을까요? 두가지 역할을 하고 있는데, 이벤트 핸들러 hijacking 없이도 trigger 를 할 수 있는 방법이 있어서요~

• load script 가 등록하는 이벤트 핸들러 hijacking
• 해당 이벤트 핸들러를 테스트에서 직접 trigger

// load 이벤트를 script 태그에 전달
script.dispatchEvent(new Event('load'))

// error 이벤트를 script 태그에 전달
script.dispatchEvent(new Event('error'))

[moresoo]

mockScriptElement 라는 이름이 document.createElement 를 mocking 한다는걸 드러내는게 아닐까요?
그래서 이 함수 내부에서 아래 로직도 함께 처리해줄거라고 기대할 것 같아요~

mocking을 유틸 밖으로 뺀 이유는 아래처럼 script 생성이 여러번 될 때의 테스트를 작성하기 위함이었는데, 성현님 말씀대로 mocking 동작이 mockScriptElement 밖에서 처리되는 게 많이 이상하긴 하네요~ 현재는 위 요구사항이 필요한 테스트는 없지만, 생긴다고 해도 mockScriptElement 유틸 내부에서 독립적으로 처리할 수 있는 방법을 찾아 적용해야 할 것 같네요! 감사합니다~ 👍 b357b7e

const { script: script1 } = mockScriptElement();
const { script: script2 } = mockScriptElement();

vi.spyOn(document, 'createElement')
  .mockReturnValueOnce(script1)
  .mockReturnValueOnce(script2);

그리고 eventListeners 는 없애도 되지 않을까요?

요건 dispatchEvent 메소드 생각을 못했습니다ㅋㅋ.. 훨씬 좋네요! f557119

[vreality64]

mocking을 유틸 밖으로 뺀 이유는 아래처럼 script 생성이 여러번 될 때의 테스트를 작성하기 위함이었는데, 성현님 말씀대로 mocking 동작이 mockScriptElement 밖에서 처리되는 게 많이 이상하긴 하네요~

아하, 전 요것도 시나리오를 나눠보면, 아래처럼 mocking 시점을 분리해서 해결할 수 있지 않을까? 생각하긴 했어요~ 만약 안된다면 다른 방법을 찾아보긴 해야겠네요 😄

const failed = mockScriptElement();
failed.script.dispatchEvent(...)

// retry 전에 setup
const success = mockScriptElement();
success.script.dispatchEvent(...)