코드를 보지 않고 프런트 엔드를 테스트할 수 있다는 것을 알고 계셨습니까?

새로운 기능을 추가하고 이미 있는 것을 약간 조정할 수 있는 여러 흐름과 양식이 있는 하나의 큰 페이지가 있습니다.

물론 테스트는 없었습니다. 그런 다음 코드를 열었지만 이해할 수 없었습니다.

익숙한 것 같나요?

첫 번째 단계: 테스트 추가

시간 제약 때문에 저는 100% 커버리지에 근접하지 않고 주로 행복한 경로에 집중하기로 결정했습니다.

또한 이것이 단위 테스트에 대한 통합을 의미한다는 것도 알고 있었습니다.

테스트 라이브러리 입력

Testing Library 및 Cypress은 정말 놀라운 도구입니다.

테스팅 라이브러리 팀의 말:

The more your tests resemble the way your software is used, the more confidence they can give you.

나는 당신에게 이것을 보여 주었다 :

https://github.com/Noriller/refreshing-way-test/blob/master/src/app.spec.jsx

다음은 발췌입니다.

describe('when you submit a form', () => {
      const titleValue = 'my title';
      const bodyValue = 'my body';

      describe('inputting both values', () => {
        beforeEach(async () => {
          await userEvent.type(getTitle(), titleValue);
          await userEvent.type(getBody(), bodyValue);
        });

        it('the title input has the input value', () => {
          expect(getTitle()).toHaveValue(titleValue);
        });

        it('the body input has the input value', () => {
          expect(getBody()).toHaveValue(bodyValue);
        });

이것이 어떤 프레임워크로 작성되었는지가 중요합니까? 아니면 구현 세부 사항?

테스트 라이브러리 API에 대해 충분히 알고 있거나 최소한 추측만 할 수 있다면 무슨 일이 일어나고 있는지 정확히 알 수 있습니다.

맹목적으로 테스트

내가 한 일은 문자 그대로 내가 작업할 페이지를 열고 이동하면서 내가 보고 있는 것을 테스트하고 클릭하거나 입력해야 하는 것을 확인한 다음 어떤 종류의 연결이 오고 가고 조롱하는지 확인하는 것이었습니다. 반환값을 문자 그대로 복사하여 (Mirage.js 또는 MSW과 같은 것이 이미 사용 중인 경우 해당 부분을 건너뛸 수도 있지만 나중을 위한 것입니다).

내가 가진 유일한 문제는 드롭다운 및 날짜 선택기에 테스트 가능성 문제가 있는 AntD 버전과 실제로 이전 단계에서 복사하여 붙여넣은 오류인 하나의 까다로운 오류 메시지와 결합되었습니다. 그래서… 항상 입력/선택이 실제로 있는지 테스트합니다. 당신이 그들에게 준 가치를 얻었습니다.

몇 가지 선택적 형식을 건너뛰는 것만으로도 행복한 길은... 전체 기능의 80%까지 도달했습니다!

투자한 시간? 하루(AntD로 인해 몇 시간이 더 소요됨)

이제 나는 그것이 무엇을 해야 하는지에 대한 개요를 갖게 되었습니다. 단계별로.

두 번째 단계: 리팩토링

처음에 코드를 건드리지 않은 경우(오류 메시지 하나를 제외하고는 분노가…). 이 단계에서는 테스트 코드를 전혀 건드리지 않았습니다.

테스트를 통해 나는 (최소한 행복한 길에서) 아무것도 깨뜨리지 않을 것이라는 것을 알았고 리팩토링, 파일 이동, 구성 요소, 파일 및 기능을 마음대로 분할할 수 있었습니다.

투자한 시간? 어느 날.

또한 구현 세부 정보를 볼 수 있었고 새 기능을 설명하기 위해 추상화할 수 있는 위치를 언급할 수 있었고 현재 코드, 사용할 수 있는 항목 및 개선할 수 있는 다른 항목에 익숙해졌습니다.

다음 단계: 새로운 기능 및 새로운 테스트

수천 줄의 코드가 포함된 수십 개의 파일을 마지막으로 작업하게 되어 두려웠던 때는 언제였습니까?

확실히 처음은 아니었지만, 다른 어떤 것보다 먼저 발을 딛고 테스트를 한 다음 리팩토링하고 실제로 "생산적인 것"을 수행한 첫 번째 작업이었습니다.

무슨 일이 일어나고 있는지, 코드가 어떻게 작동하는지에 대한 명확한 그림을 얻기 위해 며칠 투자하는 것은 매우 저렴합니다!

나는 "코드가 얼마나 끔찍한지"와 내가 하는 모든 일이 무언가를 망가뜨리고 여전히 현재 코드에 대해 지금만큼 많이 알지 못한다고 불평하는 것보다 두 배 더 걸릴 것입니다.

Bob 삼촌은 이렇게 말합니다.

The only way to go fast is to go well.

이제는 익숙한 코드베이스에 더 많은 코드와 테스트를 추가하고 내가 무언가를 깨뜨릴 때 테스트가 알려줄 것이라는 확신을 가지고 문제입니다.

TLDR

레거시 또는 익숙하지 않은 기능으로 작업해야 합니까? 아니면 당신이 오래 전에 만들었고 그것이 어떻게 작동하는지조차 모르는 테스트되지 않은 혼란일까요?

테스트를 추가합니다. (이 단계에서 확인해야 하는 코드의 양이 최소화됨)

리팩토링. (개선할 부분이 실제로 보이지 않는다면 이 피클에 포함되지 않은 것입니다.)

더 친숙한 코드베이스에서 자유롭게 작업할 수 있습니다. 그리고 무언가를 깨뜨리면 테스트가 알려줄 것입니다.

표지 사진 작성자: Mateusz Butkiewicz on Unsplash