왜 프런트엔드를 테스팅하는 것은 어려울까요?

• 매니저랑 테스팅 시스템을 구축할때 그게 얼마나 고생일지 고생끝에 얻는건 있을지 모른다
• 뭘 구축하던간에 그게 최종 프로덕트에 얼만큼 기여할지도 모른다

도구와 프로세스

• 단순히 무슨 툴을 쓰는지, TDD를 하는지, 코드 커버리지는 얼만큼 의무인지가 아키텍쳐를 대신해주지는 않는다

요약 : 관심사를 분리하는 아키텍쳐로 균형을 찾아야한다

프런트엔드 테스트는 복잡한데, 이는 종종 UI 코드가 관심사 분리 측면에서 부족하기 때문입니다. 비즈니스 로직 상태머신은 프레임워크별 뷰 코드에 얽히고 설켜 있으며 맥락을-따르는 앱 위젯은 분리된 매개 변수의 UI 빌딩 블록에 얽혀 있습니다. 모든 것이 얽혀 있을 때 신뢰할 수 있는 유일한 테스트 방법은 깨지고 비용이 많이 드는 e2e 테스트에서 "모든 것"을 테스트하는 것입니다.

이 문제를 관리하려면 특정 프로세스와 툴이 아닌 아키텍처에 의존해야 합니다.

• 일부 비즈니스 로직 흐름을 뷰에 구애받지 않는 코드(예: 상태머신)로 변환합니다.
• 앱 위젯에서 빌딩 블록을 분리하여 다르게 테스트합니다.
• 프런트엔드의 다른 부분이 아니라 백엔드와 서브시스템을 모킹 하십시오.
• 시스템 시그니처 및 규약에 대해 생각하고 또 다시 생각해 보십시오.
• 테스트 코드를 경외심을 담아 대하세요. 그것은 여러분의 코드의 중요한 부분이지, 나중에 생각하는 것이 아닙니다.

프런트엔드 및 서브시스템 간, 그리고 서로 다른 전략 간에 적절한 균형을 이루는 것이 소프트웨어 아키텍처의 기술입니다. 그것을 올바르게 하는 것은 어렵고 경험이 필요합니다. 이런 경험을 얻는 가장 좋은 방법은 노력하고 배우는 것입니다. 이 글이 학습에 조금이나마 도움이 되었으면 좋겠습니다.

참고

[번역] 테스트 가능한 프론트엔드: 좋은 것, 나쁜 것, 깨지기 쉬운 것