프런트엔드에서 테스트하는 방법

2019년 11월 21일 오후 14:00(미 동부 시간) 강연vuemeetup.com에서
이것은 Vue의 민첩한 개발에 관한 것이다. 준비 과정에서 나는 내가 토론할 시간이 없는 내용을 제기했다.이것은 Vue 프레젠테이션을 위한 것이지만 Vue에 특정한 내용이 없습니다. (이것이 바로 Vue가 성공하지 못한 이유입니다.)

왜 시험을 봐요?
민첩한 개발 환경에서 테스트의 역할은 자신감을 주는 것이다. 그러면 더욱 자주 발표할 수 있다.
나는 테스트 전단 프로젝트에 대한 견해는 주로 테스트 회귀라는 것이다.
나는 티켓 수락 기준에 부합되는 자동 테스트를 하는 것이 아니라, 내가 방금 추가한 기능이 언제든지 작업을 멈추지 않도록 테스트를 작성하는 것이다.
내가 막 새로운 기능을 추가했을 때, 나는 보통 그것이 효과적이라는 것을 안다. 왜냐하면 나는 코드를 작성할 때 그것과 상호작용을 하고 있기 때문이다.따라서 만약 내가 그것을 위해 테스트를 작성하려고 한다면, 나는 게으르기 쉽고, 충분한 기능을 포착하지 못한 테스트를 작성하는 것을 발견할 수 있을 것이다.만약 내가 테스트가 내가 실현한 기능을 포착하기 위해서라고 생각한다면, 나는 테스트를 작성하는 일이 더욱 쉽다는 것을 발견할 수 있을 것이다.

테스트를 몇 개 써야 돼요?
최근에 나는 한 항목의 테스트량을 계량화해야 한다는 요구를 받았다.나는 간단한 답안을 내놓기가 매우 어렵다. 왜냐하면 그것은 나의 스크롤 방식일 뿐만 아니라, 서로 다른 항목에서 변화가 매우 크기 때문이다.
나는 현재 전혀 테스트를 하지 않은 항목이 하나 있다.나는 오류 복구에서 내가 완성한 중요한 재구성까지 범위를 바꾸는 유일한 개발자이다.그것은 주로 계기판으로 변화에 영향을 주는 능력에 한계가 있다.그러나 이는 곧 발표되지 않을 것이다. 그 중 일부 변경 사항이 중대한 변경을 초래했기 때문에 UI의 기능이 공고해지거나 프로젝트가 발표될 날짜가 되기 전에 테스트를 추가하는 것은 비용을 증가시키고 당분간 시간/예산을 절약할 수 있을 것이라고 나는 생각한다.최종적으로, 발표하기 전에, 나는 테스트를 준비할 것이다. 그러면 나는 안심하고 발표하고 발표한 후에 추가 변경을 할 수 있다.
다른 프로젝트에서 나는 단원 테스트와 통합 테스트를 진행했다.나는 심지어 다른 브라우저의 렌더링 효과를 검사하기 위해 스크립트를 만들었다.그것은 운행하는 데 시간이 걸려서 유지하기가 매우 번거롭지만, 오류가 발생할 때마다 나의 도파민 수준이 급격히 높아진다.

저는 긴 테스트 이름 좋아해요.
테스트를 도와주고 불필요해 보이는 긴 묘사도 썼다.
예를 들어 테스트에 실패했을 때 1년 동안 코드를 보지 않은 후에 어떤 오류 메시지를 선택하시겠습니까?

it('checks for existing email', () => {})
it('opens modal with error when user submits with an existing email', () => {})

내 미래의 나는 이 터무니없는 정보 때문에 나에게 감사할 뿐만 아니라, 내가 이런 테스트를 쓰기 시작할 때, 테스트를 쓰는 것이 더욱 쉽다는 것을 발견했다. 왜냐하면 나는 내가 무엇을 테스트하고 있는지 기억하기 때문이다.어떤 경우, 이런 것들은 심지어 입장권 검수 기준에서 나올 수도 있다.
따라서 만약에 제 테스트가 각종 어음 수용 기준의 역사 기록처럼 읽힌다면 저는 코드를 더욱 자신 있게 변경할 수 있고 이 프로젝트를 처음 본 개발자도 가능합니다.

근데 저는 SNS 팬이 아니에요.
1. 최근까지 우리는 스냅숏 테스트(시각/스크린 스냅숏이 아닌 코드 스냅숏)를 멀리하기로 결정했다.
나는 이 테스트들이 매우 쉽게 작성되는 것을 발견했다.코드가 한 줄expect(myComponent).toMatchSnapshot();만 있으면 DOM이 변경되지 않습니다.그러나 문제는 이 테스트에서 유용한 단언이 나오지 않았다는 것이다.테스트는 어떤 부분이 변경되었는지 보여주지만, 상하문이 거의 없는 상황에서 이해하는 데 많은 시간이 걸릴 수 있습니다.
9개월 동안 프로젝트 코드를 보지 않은 후에, 나는 새로운 기능을 작성하고 있었는데, 스냅샷 테스트가 실패했다.스냅숏 테스트는 실패할 것으로 예상된다. 왜냐하면 내가 방금 기능을 추가했기 때문이다. 그러나 나는 내가 스냅숏에서 무엇을 검사했는지 전혀 모른다.몇 분 동안의 차이를 본 후에 나는 모든 것이 좋을 것이라고 생각했다. 기본적으로 맹목적으로 스냅샷을 업데이트해서 CI/CD 파이프라인에서 전달하도록 하는 것이다.그렇다면 어떤 일을 바꿀 때, 어떤 일이 바뀐 테스트의 가치는 무엇입니까?단언을 쓰는 데 시간을 들이고,
나는 전자메일의 정규 표현식을 테스트하는 등 일부 기능에 대해 광범위한 단원 테스트를 진행할 것이다.그러나 통합 테스트에서 테스트 단추를 사용할 때 단원 테스트 단추는 무의미한 것 같다.
나도 TDD를 거의 하지 않는다. 왜냐하면 전방 구성 요소를 작성하기 전에 단원 테스트의 범례를 작성하면 ROI를 가져올 수 없기 때문이다.CLI나 API 서버에서는 일리가 있지만, 전방에서는 큰 타격인 것 같다.
사진 출처: https://unsplash.com/@sarahmcgaughey