본문 바로가기

책과 강연/강연 및 강의

[구름 강연] 프론트엔드 테스팅과 설계

3월의 구름 강연인데, 이제야 쓰게되었다.

 

한 줄 평을 쓰면,

"물고기 잡는 법을 배우러갔는데, 최고급 오마카세를 먹여줬다"

 

왜 이렇게 적었냐면, 내가 기대한 내용은 프론트엔드 테스트를 어떻게 잘 할 수 있고, 기대 효과는 어떻고 자주하는 실수는 이런 거니 이런 부분은 이렇게 극복하였다. 등 테스트 코드를 잘 작성하는 법을 원했다.

 

하지만, 강연자님은 설계 관점에서 테스트의 중요성과 테스트를 통해서 프론트엔드를 설계하는 법을 알려주면서 여러 가지 고급 지식을 주셨다. 

 

그래서, 원했던 기술을 배운 게 아닌데, 그보다 중요한 여러 가지를 주셔서 이런 표현이 나오게 되었다.

 

프론트엔드 테스트가 어려운 이유

프론트는 특히, 테스트하기 어렵다. 왜냐하면, 너무 많은 요소가 있기 때문이다.

 

1. 제품이 동작하는 환경과 테스트 코드가 실행되는 환경이 다르다.

- 프론트는 일반적으로 브라우져(DOM)에서 실행되는 웹을 개발한다. 그러나, 테스트 코드는 터미널의 node.js 환경에서 동작한다. 이 부분은 런타임에서 차이를 만들어낸다. 

 

2. 외부 의존성이 높다.

'A가 B에 의존한다'의 정의는 'A가 B의 기능, 서비스를 사용한다'는 의미이다.

즉, B가 없으면 정상작동을 못한다는 것이다. 그런데, 프론트엔드는 특히 이런 외부 의존성이 높다.

 

- Web API : local storage/ session storage, setTimeout

- DOM : addEventListener

- BE API : 여러가지 백엔드 API

 

※ 브라우져의 종류, 클라우드의 종류, 언어의 종류/버전, 프레임워크 등 토대가 되는 환경(인프라) 그 자체도 다양할 수 있다. 다만, 이 부분은 한 번 정해지면 크게 바뀌는 부분이 아니기 때문에 이 부분은 상대적으로 괜찮다.

 

그러다보니, 외부 의존성을 설계 단위에서 제어할 수 있도록 만들어야지 테스트가 쉬워진다. 외부에서 의존성을 주입하는 방식이 대표적이다.

 

기능과 구현의 분리

※ 솔직히 잘 이해못했다! 틀릴수도 있지만, 내가 이해한대로 적겠다. 강연자의 생각과 다를 수 있다.

 

- 기능은 어떤 로직의 결과다. input을 넣으면, output이 나온다. 명세가 되고, 테스트코드로 작성하게 되는 구체적인 예시가 된다.

- 구현은 이 기능을 실제로 만드는 방법이다. web storage를 쓸 수도 있고, 다양한 방법을 사용할 수 있다. 그리고 이 부분은 중요하지 않다. 기능을 구현하는 것인데, 구현때문에 기능이 변경되거나 의존성이 생기면 안된다. 그래서, 이런 구현은 테스트과정에서 드러날 필요가 없다.

 

즉, "구현의 편의성을 위해서 설계/명세를 수정하게 되고 이는 올바른 테스트로 이어지지 못하게 하는 경우가 많아진다" 라고 이해하였다. 그렇기 때문에 위 둘은 부리되어야한다.

 

한재엽님 블로그에 나와있는 내용

잘 이해 못해서 강연자님 블로그의 있는 내용을 추가로 가져왔다.

 

작은 단위의 컴포넌트에서 구현과 기능이 합쳐져 있는 경우가 많다. 구현은 로직의 구현도 있지만, 프론트엔드 컴포넌트에서는 대부분 UI 렌더링을 의미할 것이다. 

 

위에서 설명한 것처럼 비즈니스 로직과 렌더링을 분리해야지 테스트를 할 수 있는 환경이 되기 때문에, 기능과 구현을 나누는 것이 테스트를 할 수 있는 좋은 설계가 된다.

 

하지만, 비즈니스 로직과 렌더링이 분리될 수 없는 케이스도 분명 존재한다. 그런 예외는 어쩔 수 없다.

 

마무리

굉장히 급하게 끝나는 느낌이 드는데, 어쩔 수 없다. 정리한 파일을 잃어버렸다. 정확히는 반만 살아남아있다... 

 

그래서, 강연자님이 발표한 내용과 다른 걸 쓸까봐 가장 집중해서 정리한 부분들만 적게되었다.

 

파일의 마지막에는 몇 가지 조언이 더 있다.

 

- 생명 주기와 의존성 관리 전략에 기반하여서 테스트에 용이한 설계와 전략을 고민할 것

- 제품이 안정궤도에 오르면 테스트를 작성하는 것이 더 효율이 좋다.

 

이외에도 강연 초반에는 테스트를 해야하는 이유, 테스트의 종류 등 여러가지 이야기를 더 해주셨다. 하지만, 위의 적힌 내용을 제외하고는 "구글 엔지니어는 이렇게 일한다"에 있는 내용에서 나온다.

나는 이 책을 읽고 테스트에 대해서 매우 강한 관심이 생겼고, 이를 구체적으로 운용하기 위한 부분이 궁금했다. 그런데, 비슷한 내용과 실제 운영과 관련된 내용이 안 나오니 아쉬웠다.(특히, 프론트는 이런 부분의 강의나 책이 매우 적은 거 같아서 아쉬웠다...)

다시 한 번 강조하는 최고의 책

 

다만, 위에 적혀있는 두 가지 관점은 여태까지 내가 못 본 관점이라 굉장히 인상깊고 재미있게 들었다. 특히, 테스트가 어려운 이유와 기능과 구현의 분리 두 가지는 정말 좋았다. 다른 데서는 못 들은 관점이라 생각이 들었다.

 

그래서 평가가 물고기 잡는 방법을 배우러 갔지만, 최고급 오마카세를 먹었다는 것이다. 

내용이 어려워서 기능과 구현의 분리를 질문드렸지만, 이해 못했다. 대신 오브젝트라는 책을 추천받았다. 이 책에서 오브젝트간의 통신 부분을 이해하면 쉽게 이해할 수 있을 거라 했다.

 

또, 자료가 없어서 아쉬웠는데 강연자님 블로그에 거의 모든 내용이 있어서 아쉽지 않아졌다.

 

이렇게 된 거 테스트코드는 독학으로 도전할 수 밖에 없겠다.

 

참고자료

강연자님 블로그 : https://www.jbee.io/articles/react/[Testing]%202.%20%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C,%20%EC%96%B4%EB%96%BB%EA%B2%8C%20%ED%85%8C%EC%8A%A4%ED%8A%B8%20%ED%95%A0%20%EA%B2%83%EC%9D%B8%EA%B0%80