이 부분은 조금 헷갈리는 데 이벤트 트리거는 공식문서에서 비동기로 취급하는 것 같습니다. 근데 테스트 해보니 input 이벤트 트리거는 동기적으로 동작하는 것 같습니다.

https://vue-test-utils.vuejs.org/api/wrapper/setvalue.html

문서랑 직접 비교하기 어려운게 mount, shallowMount 그리고 문서에서는 await 한 후 input element에 value랑 비교하고 있어서 api 비교를 다시 한 번 해보셔야 할 것 같아요. 문서처럼 이벤트 후에 dom 변화를 다시 테스트 코드로 살펴보려면 await가 필요해보이네요

피드백 감사합니다:) 한번 더 확인해보고 변경하도록 하겠습니다!

cf4eab5 에서 변경했습니다 :)

이 부분 밑에 테스트 코드 실행 시 터미널 창에 출력되는 문장들의 이미지를 넣어줘도 좋을 것 같습니다.

셀프리뷰 좋은 습관이네요 ~~

bba60df 에서 추가했습니다.

package.json에 "test:unit": "vue-cli-service test:unit"을 "test:unit": "vue-cli-service test:unit --watchAll"로 변경하는 내용이 있으면 좋을 것 같습니다. 테스트를 작성하고 수정할 때 마다 실행시키면 불편할 것 같네요.

tip으로 알려줘도 좋은 것 같네요 😃

피드백 감사합니다. bb0053d 에서 추가했습니다.

굳이 shallowMount를 써야 되나 고민입니다. 저는 테스트를

1. 해당 컴포넌트에서 사용자에게 보여지는 것
2. 테스트 코드만 보더라도 해당 컴포넌트를 이해할 수 있어야 함

위의 2가지에 중점을 두고 작성하고 있습니다.

하지만 shallowMount를 쓰면 child component를 랜더링을 하지 않기 때문에 동작이 달라질 수 있고 공통적으로 사용되는 컴포넌트는 따로 컴포넌트로 만들어서 사용하는 경우가 많기 때문에 테스트 코드만 보더라도 해당 컴포넌트를 온전히 다 이해할 순 없을 것 같습니다.

멘토님들 생각은 어떠신가요 ?

child component가 따로 없는 지금 같은 상황에서는 비용적인 측면에서 유리한 면이 있기 때문에 shallowMount 잘 쓰신 것 같네요
고민하신 것 처럼 여러 컴포넌트의 동작에 확인이 필요할 때는 mount를 주로 쓸 것 같네요

tip으로 알려줘도 좋은 것 같네요 😃

[제안] 아래 수정사항을 기준으로 조금 다르게 표현해봤습니다~ 😏
저희 -> 우리, 기능들을 -> 기능은

피드백 감사합니다. 4bf6625 에서 수정했습니다. 두번째는 기능들을 -> 기능들은 으로 변경했습니다.

링크가 비어 있는데 나중에 추가되는 걸까요? 🙄

넵 마지막에 추가할 생각입니다 :)

f671d43 에서 추가했습니다.

처음에 control을 보고 어떤 걸 말하는지 몰라서 멈칫해서 코드를 봤는데 input을 의미하는 거였군요. 😅

input or 할 일 입력란과 같이 좀 더 명확히 알려주면 어떨까요? 😃

변경한다면 일괄 수정이 필요하겠군요.

피드백 감사합니다.
항상 input과 관련된 것들은 control로 표현해왔는데 많이 어색한가요 ?
우선 109c2c0 에서 control 창이라고 변경을 했습니다.

저는 흥미롭게 느꼈는데 다른 분들의 의견도 궁금하네요.
저 같은 경우, 실무에선 개발자-디자이너 간에 사람마다 조금 차이가 있지만 인풋/입력란/텍스트 입력란/텍스트 박스 이런 식으로 말해왔고 들어왔어요.
창의 경우 팝업류 UI 에서 사용했었어요. 영문명인 window로 사용하는 것으로 알고 있었어요~ 😃

5f423c8 에서 control창을 input창으로 변경해주었습니다 :)

[제안]
글 윗 부분에서 추가하기 버튼 식으로 표현을 해와서 동일하게 맞춰주면 좋을 것 같아요 😄

피드백 감사합니다. f43218d 에서 변경했습니다 :)

describe을 조금 더 설명 적어주어도 좋을 것 같네요.

피드백 감사합니다 :) 저는 테스트 코드를 작성할 때 describe - context -it 구조로 작성을 하고 있는데요. 예를 들어 밑에처럼

describe('App', () => {
   context('when logged in', () => {
     it('renders profile', () => {})
  })
})

App when logged in renders profile 이런식으로 문장이 이어지게 작성하고 있습니다. 이렇게 작성하는 것에 대해서는 어떻게 생각하실까요 ?

얘기하신 describe - context -it 룰에 맞춰서 작성하시는 것도 좋아 보입니다 👍

저도 다른 분들은 어떻게 하고 계신지 궁금하네요. 🙄
회사에서는, 한글로 작성하고 있는데 describe에는 제목을, 테스트 로직이 있는 it 대신 test에는 검증할 내용을 작성하고 있어요.

한글을 쓴다면 저도 describe에 테스트하는 컴포넌트 이름을 적고 it보단 test를 사용해서 검증할 내용을 작성할 것 같습니다. 명호님이 사용하고 계시는 테스트 코드의 예시를 하나 들어주실 수 있을까요 ? 😊

describe('요소 기능 제한 테스트', () => {
  // ...
  describe('체크 기능 테스트', () => {
    test('허용 리스트에 존재하면 제한된 것으로 간주한다', () => {
      // ...
    });
    test('리스트에 존재하지 않으면 제한되지 않은 것으로 간주한다', () => {
      // ...
    });
  });
});

Webstorm 기준 IDE에서 결과를 볼 때 아래와 같이 나와요.

▼ √ Test Results
  ▼ √ xxx_test.ts
    ▼ √ 요소 기능 제한 테스트
      ▼ √ 체크 기능 테스트
            √ 허용 리스트에 존재하면 제한된 것으로 간주한다
            √ 리스트에 존재하지 않으면 제한되지 않은 것으로 간주한다

컨벤션에 따른 차이일 것 같아요. 😄 (저흰 테스트 코드에 대한 컨벤션은 없고 1세대 개발자들을 따라서 작성을...ㅋ)

Vue.js github에서는 테스트 영역마다 다르기도 하네요. 🤔
ex 1) ssr-string.spec.js
ex 2) show.spec.js

개인적으론 동우님이 작성하시는 스타일로 해보는 것도 좋을 것 같아요 👍

테스트 코드 작성에 정답은 없는 것 같습니다 ㅎㅎ 개인적인 생각으론 다른 사용자들이 보기에 해당 테스트의 의도가 가독성 있게 잘 읽힌다면 상관 없을 것 같습니다. 혹시나 jest에서 context를 사용하시게 된다면 jest-plugin-context 라이브러리를 사용해보시면 좋을 것 같습니다. context에는 when, with를 사용해서 작성하며 테스트 검증문의 길이를 줄여주고 가독성을 높여줍니다.

https://www.betterspecs.org/#contexts

처음 알게되네요. 공유 고마워요! 🚀

저도 여기에 제 의견을 좀 공유해 드리고 싶은데요..! 이미 다들 잘 애기 나눠 주셔서 넘 늦게 온거 같기도 한데.. ㅎㅎ

1. 일단 저도 동우님처럼 describe, it 단위로 작성하는게 편한 것 같습니다. 테스트 파일을 쪼개기 나름인 것 같아요.
2. 그리고 보다 보니까 저는 보통 expect 안에 여러 개의 API를 연결해서 바로 넣는 것보다는 아래와 같은 형태로 작성하는데요. 이게 좀 더 어떤 걸 테스트 하는 건지 눈에 잘 들어오는 것 같아요. 뭐 이런건 취향 차이일수 있으니까 ㅋㅋ

it("renders title", () => {
    const wrapper = shallowMount(App);
    const headingText = wrapper.find("h1").text();
    expect(headingText).toMatch("Todo App");
  });

셀프리뷰 좋은 습관이네요 ~~

control 창보다 쉽게 파악할 것 같은데 어떻게 생각하시나요?

피드백 감사합니다 :) 말씀하신대로 수정해보겠습니다!

5f423c8 에서 control창을 input창으로 변경해주었습니다 :)

조금 더 명시적으로 description 작성해주셔도 좋을 것 같네요
할 일 입력값을 입력할 때 입력값이 연결된 vue data 에 저장된다.

피드백 감사합니다:) 이 테스트 코드 의도 자체가 input event 발생에 대한 테스트입니다.

it('listens input event when change input value', () => {})

이런식으로 적어주는 것에 대해서 멘토님은 어떻게 생각하시나요 ?

테스트코드에 의도 자체가 이벤트 리슨이면 의도하신대로 적는게 맞는 것 같아요.
input events listen을 test하는거면 함수 콜만 비교해도 될 것 같네요 ,
뒤에 비교하는 부분 vm.text랑 값을 비교하는 부분이 있어서 그 부분이랑 매칭이 되면 더 좋을 것 같아요

#76 (comment)

문서랑 직접 비교하기 어려운게 mount, shallowMount 그리고 문서에서는 await 한 후 input element에 value랑 비교하고 있어서 api 비교를 다시 한 번 해보셔야 할 것 같아요. 문서처럼 이벤트 후에 dom 변화를 다시 테스트 코드로 살펴보려면 await가 필요해보이네요

테스트 내용이랑은 크게 상관없지만 코딩 스타일 + ui 적으로 피드백 드려요

• handleClick -> addTodo ui 이벤트에 맞춘 이름 보다 어떤 행위인지 명시적인 메소드 명이면 더 좋을 것 같습니다
• form으로 쓰기 때문에 버튼 type=submit으로 받아서 enter 이벤트도 쉽게 받을 수 있도록 처리해서 form에서 submit이벤트로 받아서 할 일 을 추가해주면 더 좋을 것 같네요

피드백 감사합니다 :) 말씀해주신대로 변경해보겠습니다!

• fd965a2 에서 handeClick을 좀 더 명시적으로 handeClickAddTodo로 변경해주었습니다.

• 한번 더 생각해보니 form 태그를 굳이 써야 되나 라는 생각을 가지게 되어 54b8735 에서 form -> div로 변경해주는 작업을 했습니다.

line을
given
when
then
에 맞춰서
setValue랑 awiat단락은 묶어주면 더 좋을 것 같습니다

given/when/then 좋습니다.

피드백 감사합니다 :) 패턴에 맞춰서 변경해보겠습니다!

5c4ab79 에서 변경했습니다 :)

여기도 클릭이벤트 테스트 라는 description 보다는
할일 추가 테스트 혹은 할 일 작성 후 투두 리스트에 제대로 값이 있는지 테스트 등 조금 더 명시적으로 적어주시면 좋을 것 같습니다

피드백 감사합니다 :) 이 부분도 #76 (comment) 마찬가지로 테스트 의도가 click event가 발생되는 것에 두고 있어서

it("listens click event when click '추가하기' button", () => {})

로 작성하는 해보려고 합니다. 멘토님 의견은 어떠실까요 ?

어 이 부분도 테스트 스펙이랑 확인하는 과정을 보면 할 일을 추가 버튼을 누르고 할일이 추가된 것을 확인하는 테스트 같은데 어떻게 생각하시나요?

말씀하신대로 해당 테스트 내용이 이벤트 테스트라기보단 할일이 추가된 것을 확인하는 테스트 처럼 보입니다. 위에서 말씀해주신 것처럼 함수 콜에 대한 부분을 작성해보겠습니다 !

생각해보니 클릭 이벤트를 테스트 하는 것 보단 기능 구현과 일치시키는 게 맞다고 생각 됩니다.
2988160 에서 테스트 검증문을 수정했습니다 :)

@dngwoodo 동우님 요 부분은 지난번 PR에서 말씀 드렸어야 했는데 요건 단어 하나만 툭 튀어나오는 것 보다 좀 더 설명이 들어가면 좋을 것 같아요 😄

할 일 추가하기의 구현 순서는 다음과 같으며 최종 코드는 여기서 확인하실 수 있습니다.

대략 이런 식으로..? 😄

피드백 감사합니다 :) baf2578 에서 변경했습니다.

피드백 감사합니다:) 10bfb48 에서 수정했습니다. 커밋을 나눌 필요가 있어보이는데 실수로 두가지 수정을 한 커밋에 넣어버렸네요..🥲

그 저희가 백틱은 인라인 코드에만 적용하는게 좋을 것 같아서 별도의 강조 표시가 필요하시다면 큰 따옴표나 * 쓰면 좋을 것 같습니다 😄

@dngwoodo 님 안녕하세요 이쪽 백틱쪽만 한 번 ""로 고치는게 좋은 부분 있는지 보면 좋을 것 같네요

문서 전반적으로 맞춤법 검사를 한번 하면 좋을 것 같아요! 😄

피드백 감사합니다:) 10bfb48 에서 수정했습니다.

한가지 -> 한 가지 로 수정

저도 여기에 제 의견을 좀 공유해 드리고 싶은데요..! 이미 다들 잘 애기 나눠 주셔서 넘 늦게 온거 같기도 한데.. ㅎㅎ

1. 일단 저도 동우님처럼 describe, it 단위로 작성하는게 편한 것 같습니다. 테스트 파일을 쪼개기 나름인 것 같아요.
2. 그리고 보다 보니까 저는 보통 expect 안에 여러 개의 API를 연결해서 바로 넣는 것보다는 아래와 같은 형태로 작성하는데요. 이게 좀 더 어떤 걸 테스트 하는 건지 눈에 잘 들어오는 것 같아요. 뭐 이런건 취향 차이일수 있으니까 ㅋㅋ

it("renders title", () => {
    const wrapper = shallowMount(App);
    const headingText = wrapper.find("h1").text();
    expect(headingText).toMatch("Todo App");
  });

@dngwoodo 요거 인풋 창도 정리해주세요 😄

요게 3번 맞죠?