<Testing>에서는 테스트 관련 스터디한 글을 가장 빠르게 받아보실 수 있습니다.
태그보기
사진보기
제목보기
태그검색
Search
jest 유닛 테스트 → 적용하는 데 오래 걸릴 것 같지 않음
cypress e2e 테스트, storybook → 무경험
cypress와 storybook은 같이 적용해야 하는가?
먼저 cypress와 storybook의 목표가 무엇인지 알아야 한다.
1.
저는 사이프레스 컴포넌트 테스트를 많이 사용하는 오픈 소스 리액트 컴포넌트 라이브러리를 운영하고 있는데, 정말 재미있습니다. 구성 요소의 동작은 동영상을 로드하고 재생할 수 있는 능력에 크게 기초합니다.
그래서 제스트는 말도 안 되는 Mocking을 할 필요 없이 완전히 불가능했다.
사이프레스가 할 수 있는 일의 절대적인 한계까지 밀어붙여야 했고 몇몇 테스트들은 제가 원하는 것보다 더 형편없지만, 실제로 경쟁할 수 있는 다른 것은 없습니다.
스토리북을 아직 안 써봤어요.
하지만 믿을 수 없을 정도로 흥미로워 보여서 조만간 기회를 잡을 수 있기를 바라.
지금까지 Cypress Component Tests에서 놀라울 정도로 인상 깊었습니다. 브라우저에서 실제 응용 프로그램을 실행하면서도 일부를 테스트할 수 있는, 제가 항상 원했던 수준의 테스트 수준의 추상화입니다.
cypress // https://velog.io/@averycode/Cypress
•
자바스크립트 E2E 테스트 프레임워크
TDD jest, cypress, storybook
2022/05/05 12:52
icoa
다룰 주제들
1.
실행하기
2.
테스트 작성하기
3.
디버깅하기
4.
성능 측정 테스트 자동화
5.
브라우저 지원 범위
실행하기
병렬로 테스트 실행하기
작성한 테스트 케이스 묶음(test suite)을 다양한 브라우저 인스턴스에서 실행시키려면 선택한 테스트 러너(test runner)에 의존해야 한다. 예를 들어 Jest
를 사용할 때는, 동시에 실행시킬 브라우저 세션 개수를 정의하기 위해서 maxWorkers 옵션을 설정한다.
Puppeteer로 E2E 테스트하기 팁 - Puppeteer와 함께 속도 높이기!
2022/03/13 15:02
icoa
이 글에서는 개별 모듈 단위의 작은 단위 테스트 대신, 여러 모듈이 조합된 형태를 하나의 단위로 보고 좀 더 큰 규모의 단위 테스트를 작성하기를 권장한다. 용어를 통일하기 위해 지금부터는 상대적으로 큰 규모의 단위 테스트를 통합 테스트라고 부르도록 하겠다.
통합 테스트 작성하기
통합 테스트를 작성하기 위해서는 먼저 단위를 나눌 경계를 결정해야 한다. 예를 들면 액션 생성자와 리듀서, 스토어를 묵어서 테스트할 수도 있고, 스토어와 컨테이너 컴포넌트만 묶어서 테스트할 수도 있다. 나누는 범위에 따라 각각의 장단점이 있으므로 상황에 따라 적절한 범위를 선택하면 된다. 여기서는 개별 모듈 단위의 테스트와의 차이를 명확하게 비교하기 위해 스토어와 라우터를 생성하는 메인 모듈을 제외한 모든 모듈을 묶어서 테스트하도록 하겠다.
DOM에서 애플리케이션의 상태 확인하기
이제 애플리케이션의 상태를 기준으로, 현재 상태를 시각적으로 나타내는 부분과 사용자의 입력을 받아 현재 상태를 변경하는 부분을 모두 테스트했다. 그럼 이제 모든 부분에 대한 테스트를 작성했다고 할 수 있는걸까? 음, 사실 아직 자동화할 수 있는 테스트가 남아있다. 바로 DOM에 대한 테스트
통합 테스트(Jest) vs E2E 테스트 (Cypress)
이제 모든 테스트가 끝났다. 작은 범위의 단위 테스트와 비교해서 큰 범위의 통합 테스트가 갖는 장점도 이제 잘 알게 되었을 것이다. 그런데 문제는, 원래 다루기로 약속했던 Cypress에 대한 내용은 아직 언급조차 되지 않았다는 점이다. 사실 Jest와 react-testing-library는 아주 강력한 도구이며, 이 둘을 잘 사용하면 굳이 Cypress를 사용하지 않더라도 효율적인 테스트를 작성할 수 있다. 그렇다면 Cypress는 어떤 문제를 해결할 수 있는걸까?
첫째로, Jest는 실제 브라우저가 아닌 JSDom을 이용한 가상의 브라우저 환경에서 실행되기 때문에 제약이 있다. 예를 들어, 브라우저의 렌더링 엔진을 사용할 수 없기 때문에 실제 렌더링된 결과인 픽셀 정보를 받아올 수 없고, URL 변경 등을 처리하는 방식이 달라서 라우터의 동작을 테스트하기가 어렵다.
앞서 작성한 코드에서 StaticRouter를 매번 목킹해서 주입하고 있는 이유는 애플리케이션 코드의 BrowserRouter를 그대로 사용할 수 없기 때문이다. Cypress는 실제 브라우저 환경에서 실행되기 때문에 이러한 제약 없이 브라우저의 모든 기능을 사용할 수 있다.
둘째는 개인적으로 가장 중요하다고 여기는 내용인데, 바로 디버깅의 용이성이다. 사실 Jest의 인터렉티브한 CLI 환경은 상당히 강력해서 테스트가 실패했을 때 꽤나 유용한 정보를 제공해준다. 하지만 문제는 실제 화면에 표시된 UI를 볼 수 없다는 점이다. 실제 화면에 표시된 UI를 보지 못한 채 프론트엔드 코드를 작성하거나 디버깅을 하는 것은 마치 암흑속에서 코딩하는 것처럼 괴로운 일이다. 특히 위에서 설명한 것처럼 DOM을 사용해 애플리케이션의 상태를 검증할 때, 테스트가 실패하는 이유를 찾으려면 console.log()를 열심히 찍어보거나 복잡한 HTML 문자열을 눈이 빠져라 들여다볼 수 밖에 없다.
반면, Cypress는 브라우저에서 실행되기 때문에 실제 화면에 표시된 UI를 보면서 코드를 작성하거나 디버깅을 할 수 있다. 뿐만 아니라 테스트를 위해 실행한 모든 명령과 해당 시점의 애플리케이션 상태가 명령 로그에 모두 기록되기 때문에, 마치 녹화된 비디오를 돌려보듯이 쉽게 디버깅을 할 수 있다. 또한 브라우저의 개발자 도구를 그대로 사용할 수 있기 때문에 console.log()에 의지하는 것보다 훨씬 더 인터렉티브한 환경에서 디버깅을 할 수 있다.
이 외에도 Cypress는 사용자의 입력을 시뮬레이션할 수 있는 API를 제공하여 직접 DOM 이벤트를 발생시키는 것보다 훨씬 직관적으로 테스트 코드를 작성할 수 있고, 서버 데이터를 목킹할 수 있는 API를 제공하여 특정 라이브러리에 종속되지 않고도 편리하게 서버 데이터를 목킹할 수 있는 장점이 있다.
E2E 테스트와 Cypress
이처럼 Cypress는 기존 Jest 기반의 통합 테스트보다 더 나은 테스트 환경을 제공한다. 하지만 본격적으로 Cypress를 다루기 전에 먼저 전통적인 E2E 테스트와 Cypress의 차이점에 대해 잠깐 언급하고 넘어가도록 하자.
통합 테스트(Jest) vs E2E 테스트 (Cypress)
2022/05/05 12:50
icoa
가정문 올바르게 쓰기
불필요한 act 사용
개발자들이 act warning 메시지를 볼 때마다 이런 식으로 act로 감싸려고 하는데 render나 fireEvent는 이미 act로 래핑된 함수라 무의미한 행동이다. 워닝 메시지가 발생한다면 테스트가 종료된 후 상태 변경이 일어난 것 이므로 이에 대한 코드 수정이 필요하다.
쿼리를 올바르게 쓰기
ByRole를 더 활용하기
위와 같은 형태의 버튼도 쿼리가 가능하다는 장점이 있다.
접근성 role를 불필요하게 등록하지 않기
button은 button이라는 role을 가진 요소이므로 등록이 불필요하다. 이와 같이 테스트를 한답시고 함부로 role을 명명하고 등록하면 안된다. 우선 접근성에 대한 충분한 학습이 필요하다.
waitFor 내에서 사이드 이펙트 수행하지 말기
RTL 실수 체크
2022/05/05 12:57
icoa