NHN FORWARD

운이 좋아서 다녀올 수 있었던 행사. 주로 세션 부분, 특히 프론트엔드 쪽을 들었고 인상적인 내용을 기록합니다.

점진적으로 프론트엔드 프레임워크 교체하기 Angular JS to Vue

프레임워크 교체

교체 고민의 이유

• AngularJS의 경우 지원 중단 상황
  • 지원이 중단된 프레임워크를 계속 사용할 경우 앞으로의 신규 기능 개발이 힘들 것으로 예상
  • 커뮤니티에서도 서드파티 패키지를 미지원

• 직원의 커리어에 도움이 되지 않고 개발자 채용이 어려움

• 최신 프레임워크의 장점 수용의 필요성

왜 점진적으로 바꿔야 할까요?

리스크가 너무 크니까요!

디자인, 기능을 똑같이 다른 프레임워크로 구현해야 한다면, 시간적 비용도 만만찮게 듭니다.

어떻게 하면 될까요?

• 컴포넌트 단위로 분해 후 하나씩 하나씩 적용해 배포하는 방식을 취했습니다.

마이크로 프론트엔드

웹 페이지를 이루는 요소들을 각각 개발하여, 한 페이지에 합치는 방식

리스트가 낮으며 결과물을 빠르게 확인 가능하다는 장점

교체 전 필수 준비 사항

사전 기능 파악

• 잘 정리된 문서와 꼼꼼한 기능 파악
  • 기획서
  • QA 테스트 케이스 문서
  • 기존 설계 문서
• 코드를 통한 기능 파악
• 개발 계획 세우기

점진적으로 프레임워크 교체

총 3가지 방법을 고민했습니다

SPA를 포기하고, 별도 페이지로 분리

• js, css의 충돌 가능성이 적음
• 해당 파일만 웹팩이 정확히 번들
• 페이지 이동 시 깜빡이는 현상

SPA를 유지하되, iframe 사용

• 첫 번째 방법의 장단점을 모두 가지고 있었다
• XSS 보안에 취약

XXS(Cross Site Scripting) 보안

게시판, 웹 메일 등에 삽입된 악의적인 스크립트에 의해 페이지가 깨지거나 다른 사용자의 사용을 방해하거나 쿠키 및 기타 개인 정보를 특정 사이트로 전송시키는 공격

> > <SCRIPT>alert("페이체크");</SCRIPT>
> >

• 프레임 간 통신 방법 제약
• iframe 내부 라우터를 모두 부모인 앵귤러에서 처리

SPA 유지 vue in angularJS

• vue의 특징 덕에 멀티 인스턴스 가능
• 가볍고 빠름
• 한 프레임에서 동작하므로 두 프레임워크 간 데이터 공유 등이 쉬움
• js, css 용량이 늘어나고 충돌 가능성
• 라우터 관리는 AngularJS에서만 하도록 처리 필요

교체 전후 비교

• 부모 컴포넌트인 앵귤러 내에서 뷰의 인스턴스 생성
• 다이나믹 컴포넌트(뷰의 기능) 활용
• 비동기 컴포넌트 사용으로 필요할 때만 특정 파일을 로드
  • 프로미스를 리턴하는 함수를 등록(지역적 인스턴스로 쓴다)

두 프레임워크 간 통신하는 방법

• 뷰의 리액티브 시스템 활용
  • 처음 앵귤러 라우터 측에서 뷰에게 프롭스로 state를 넘긴다
• 뷰엑스의 디스패치, 커밋 사용
  • 앵귤러 내부에서 뷰의 액션 리스너를 등록하고, 뷰에서 일어나는 변화를 감지할 수 있도록 사용

실용적인 프론트엔드 테스팅 전략

프런트엔드 테스팅 이해하기

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

• 테스트 코드란 입력과 출력을 검증하는 것

  • 백엔드는 데이터로 모두 검증 가능
  • 프론트엔드는 사용자의 액션이 입력, 출력은 화면이 바뀌는 것으로, 입출력을 데이터로 검증하기 힘듦
  • 특히 출력 데이터(시각적) 검증이 어렵다
    • 코드 관점(html, css)
    • 렌더링한 화면

• 프론트엔드 테스팅은 테스트가 성공했다고 하더라도, 의도된 결과 값을 준다고 자신할 수 없다

  • 게다가 프론트 테스팅 코드는 백엔드에 비해 비해 리팩토링을 할 적 별 도움이 되질 않음

프론트엔드 테스트는

• 구현 상세에 대한 테스트를 지양하고, 동작을 테스트하려 노력해야 한다

시각적 테스트와 기능적 테스트

	시각적 테스트	기능적 테스트
용도	회귀 테스트	모든 종류의 테스트
TDD	불가	가능
실행 환경	브라우저 외부	브라우저 내/외부
결과 확인	이미지 확인을 위한 UI 필요	커맨드 라인에서 확인 가능
CI 연동 / 이력 관리	이미지 확인/관리를 위한 별도 UI 필요, 문서화 기능이 없음	빌트인 기능으로 가능
테스트 도구	유료 외부 서비스 필요	너무 다양

시각적 회귀 테스트의 문제

• 운영체제, 브라우저 등의 렌더링 방식 차이

• 이미지/폰트 로딩 시간, 커서, 애니메이션 등으로 인한 캡처 시점의 차이

• 결과 확인 및 이력 관리가 어려움

• 케이스 별 이미지 파일 생성 / 관리가 어려움

• 테스트 실패 시 원인 파악이 어려움

기능적 테스트를 기반으로 한 시각적 테스트

• 기능적 테스트에서 시각적 요소 의존성을 제거

  • 기능만을 위한 의미 있는 클래스명 사용
  • 테스트를 위한 별도의 속성 값 사용

• 기능이랑 별개인 시각적 테스트도 필요

단위 테스트와 통합테스트

• 테스트는 비용이기에 불필요한 테스트는 최소화 해야한다

• 단위 테스트는 필수가 아니다 동어 반복적인 테스트

• 핵심 알고리즘을 가진 모듈만 유닛 테스트

• 서버에서 데이터를 가지고 와서 뷰에 뿌리는 단위로 하길 추천