Pay it forward

혼자 공부하면서 정리한 내용입니다. 자세한 내용은 공식문서를 봐주세요 Actionability Cypress의 명령은 DOM과 상호작용 하기 위한 것이다. 예를들면 .click(), .dbclick(), .type(), .clear(), .check(), .trigger(), .selectFile() 같은것들.. 기본적으로 이 챕터에서 말하고싶은것은 어떤 이벤트가 발생하기 전에 그 이벤트가 발생할 수 있는 상황인지 Cypress가 보이지 않는곳에서 모든것을 체크한다는 개념이다. 당연히 4초동안. 무슨말이냐하면 뭔가 사용자가 이벤트를 발생시키기 전에 적어도 그 버튼이 진짜 눈에 보여야 사용자가 클릭을 하든 드래그를 하든 뭘 할수 있을테니, 진짜 눈에 보여? 다른 요소에 가려져있지는 않아? 이런것들을 이벤트..

Commands vs assertions 최신의 모든 웹은 동기적으로만 작동하기 않기 때문에 Cypress의 핵심기능 중 하나인 Retry에 대해 이해할 필요가 있다. 개발자가 DOM 렌더링이나 response 시간에 대해 신경 쓰지 않고 Cypress코드를 작성할 수 있게 해주는 기능이 바로 Retry기능이기 때문이다. 굳이 신경쓰지 않아도 Cypress는 잘 작동하겠지만 더 적은 코드로 효율적인 테스트를 하기 위해서는 Retry기능을 이해할 필요가 있다. 아래는 6개의 Command과 2개의 Assertion이 있다. 위 테스트 코드는 잘 통과한다. 처음에 말했듯이 최신의 웹은 동기적으로만 작동하지 않기 때문에, 위 테스트코드에서 DOM요소를 쿼리하고 오직 2개만 있는지 확신할 수 없다. 세 가지 경..

What is E2E Testing? E2E테스트는 end-to-end 테스트의 약자로 쉽게말하자면 프론트엔드(브라우저)부터 백엔드, 서드파티api까지 전부 통틀어 테스트하는 것을 뜻한다. 그래서 내가 개발한 앱을 통틀어 하나로써 제대로 동작하는지 테스트하는데 유용하게 사용된다. Cypress 의 E2E테스트는 진짜 유저가 우리의 앱을 통해 하는 행동, 즉 URL을 방문하고 콘텐츠를 보고 버튼을 클릭하는 등의 행동을 그대로 작동한다. 이런방식의 테스트는 테스트와 사용자 경험과 동일한지 확인하는데도 도움이 된다. E2E테스트는 앱이 의도한데로 작동되는지 전체를 처음부터 끝까지 테스트하는데 유용하나, 준비, 운영, 유지가 컴포넌트 테스트보다 더 어려울 수 있다. 왜냐하면 이 테스트는 백엔드 설정까지 필요할 ..

Cypress가 동작하는 코드를 이해하기 위해서 몇 가지(Queue, Chains of Commands, Assertion, timeout, retry 등) 개념에 대해 이해할 필요가 있다. 공식문서의 Core Concepts Part를 읽으며 정리한 내용이다. 공식문서: (https://docs.cypress.io/guides/core-concepts/introduction-to-cypress#What-you-ll-learn) Cypress Can Be Simple (Sometimes) Cypress의 장점은 하는일에 비해 코드의 양이 적다는 것이다. 그리고 쉽다. 각 Commands를 공식문서에서 찾아보지 않아도 어떤 내용인지 알 수 있다. 1. /posts/new 페이지에 접근하여 2. Input ..

처음에 Cypress를 실행하면 @types/mocha 나 @types/jest를 설치하라고 에러 메시지가 나오는데 정답은 아니고 typescript cypress eslint설정하는 방법이 있다. 일단 Cypress ESLint Plugin 설치 yarn add eslint-plugin-cypress --dev // eslintrc.json { "plugins": [ "cypress" ] } // eslintrc.json // 각 rule의 내용은 검색해보기 { "rules": { "cypress/no-assigning-return-values": "error", "cypress/no-unnecessary-waiting": "error", "cypress/assertion-before-screensho..

사실 테스트 코드에 대한 관심은 예전부터 있었는데 프론트엔드의 TDD 실용성에 대한 의문도 있었다. 이번에 공부를 하면서 프론트엔드에서 작성할 수 있는 테스트가 여러 분류가 있고, 그중에 내가 실제로 수동으로 매번 하는 테스트가 바로 integration test와 E2E test의 중간 정도 된다는 것을 알았다. 내가 생각했던 TDD의 실용성에 대한 부분이 '테스트 코드' 하나로 퉁칠 수 있는 부분이 아니라 '어떤' 테스트를 '언제' 할것인지에 따라 효율적으로 사용할 수 있을 것 같다는 생각이 들었다. 결론부터 말하자면 나는 '코드를 수정,개선하거나 내부 로직을 바꿀 때' 'E2E테스트'가 필요했다. 시험 삼아 E2E test 프레임워크로 유명한 Cypress를 이용해서 매번 손으로 직접 브라우저에서 ..