더 좋은 테스트를 위한 10가지 기교 만들기

# 1 - 사고 문서

Your company wiki can be outdated. Tests can't.

모든 사람은 좋은 문서를 원한다.불행히도 최신을 유지하기는 어렵다.나는 테스트가 어떤 방식으로 문서의 일부분을 대체할 수 있다고 믿는다.테스트는 응용 프로그램의 행동을 잘 묘사했다.
내가 너에게 내가 쓸 수 있는 예를 하나 들어 줄게.

// Shop.spec.js
it('should show list of product', () => { /* ... */ })
it('should hide non-available products', () => { /* ... */ })
it('should display a discount label when available', () => { /* ... */ })
it('should paginate when > 10 products', () => { /* ... */ })

파일 이름과 네 개의 설명을 읽으면서 나는 이미 이 기능과 업무 규칙을 알게 되었다.
또한 사용 불가능한 제품을 숨겨야 한다는 테스트가 중단되면 어디서부터 조사를 시작해야 할지 확실하게 알고 있습니다.

#2 - 격리 테스트

테스트 파일을 더욱 잘 구성하기 위해서는 같은 테스트에서 관련 단언을 그룹화할 수 있다(= 동일it()/test().가능한 한 너의 몸매를 유지해라.비교적 작은 테스트는 이해하고 유지하기 쉽다.
때때로 우리는 전체 과정을 테스트해야 한다.하나의 지불 절차처럼 당신은 몇 가지 다른 절차가 있습니다 (즉 지불 정보 > 사용자 주소 > 확인).
큰 테스트를 만드는 것과 각 단계의 테스트를 만드는 데 주저하는 경우, 2단계는 1단계에 따라 결정됩니다. 첫 번째 옵션을 선택하십시오.더 긴 테스트를 진행할 수 있다.
테스트 사이에서 상태를 공유하는 것은 나쁜 생각이다.그것들은 디버깅하기 어려울 뿐만 아니라, 곧 또는 잠시 후, 당신은 부작용으로 인한 이상한 문제에 직면하게 될 것입니다.시종 테스트 격리를 유지하다.테스트는 서로 의존해서는 안 된다.

#3 - 플랫 유지

나는 어떤 조건도 쓰지 않는 경향이 있다(if/else/...)내 테스트에서만약 테스트에 If 조건이 있다면, 두 가지 다른 것을 테스트하고 있을 수도 있습니다.이것은 당신의 테스트에 너무 많은 책임이 있을 수 있다는 것을 의미한다.
고체의 S(S= 단일 책임 원칙)를 기억하십시오.만약 그것이 커피를 끓일 수 있다면 빵을 구워서 예보를 가져와라...무슨 문제가 생겼나봐요.

#4 - 네가 통제할 수 없는 것만 비웃는다

Every time we mock, we diverge from the real world scenario.

따라서 가능한 한 피해야 한다.그러나 때때로 우리는 다른 선택이 없어서 그것을 사용할 수밖에 없다.다음은 유일한 예외입니다.

외부 API 호출(HTTP GET/POST/...)

브라우저 API(로컬/세션 스토리지, 네비게이터 등)에 사용됩니다.

... 시간 기반의 것들date, 랜덤 방법.

시간으로 말하자면, 만약 당신이 타이머를 테스트하고 있다면, 타이머가 필요로 하는 x초 안에 파이프를 막지 마세요.시계 따라하기!

# 5 - 반복 단언 피하기(forEach/...)

흔히 볼 수 있는 오류는 순환 중 테스트 목록이다.
예: 30개를 불러오는 페이지를 테스트하고 싶습니다.

import fakeDataProducts from '../fixtures'

it('should shows list of product', async () => {
  const wrapper = await render(ProductList)
  fakeDataProducts.products.forEach(product => {
    expect(wrapper.find(product.name))
      .toBeInTheDocument()
  })
})

여기 왜 그래?

단언이 너무 많음: 여러 단언이 테스트 세트의 실행을 늦출 수 있습니다.

무가치 테스트: 한 항목의 존재를 단언하는 것은 좋은 생각일 수 있다.그러나 테스트 항목의 존재는 별로 가치가 없는 것 같다.

예외: 그룹의 모든 요소가 다른 용례를 대표할 때.

#6 - 사용자와 동일한 방식으로 애플리케이션 테스트

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

— Kent C. Dodds

당신이 가장 좋아하는 소셜네트워크서비스에 로그인하고 싶다고 가정해 보세요.사용자 이름과 비밀번호를 입력하십시오.그리고: DOM에서 id="login-form-btn" 검색 버튼을 사용할 수 있습니까?아니면 로그인 버튼을 누르시겠습니까?왜 테스트 방식이 달라요?
페이지에 "로그인"키워드가 이미 있는 경우 액세스 가능 속성(즉, aria-label,...)을 사용하여 항목을 조회할 수 있습니다.이런 방식을 통해 구성 요소의 접근성을 강제로 실현할 것입니다.

#7 - 통합 테스트 지원

너는 아마 Martin Fowler의 블로그Testing Pyramid를 읽은 적이 있을 것이다.요컨대 이 블로그는 단원 테스트(빠르고 저렴하고), 집적 테스트와 단말기 테스트(느리고 비싸다)를 많이 쓴다고 말한다.
하지만 이 게시물은 2012년에 작성됐다.8년 전!나는 우리가 오늘 서로 다른 규칙으로 다른 게임을 한다고 믿는다.
Redux/Vuex 상점에 대한 단원 테스트를 진행할 자신이 없습니다.나는 이전에 한 적이 있다.여러 번...그러나 버그의 수는 변하지 않았다.왜?버그와 회귀는 보통 작은 블록 코드에 없기 때문이다.우리는 그들이 더욱 높은 수준에 처해 있다는 것을 발견했다.

(셀 및 통합 테스트)
집적 테스트는 단원 테스트보다 더 비싸다.하지만 이것은 가치 있는 번거로움이다.

# 8 - 세부 사항 구현 방지

"like 단추"를 테스트하고 싶다고 가정하십시오.너는 이런 일을 하고 싶을 수도 있다.

const wrapper = mount(<LikeButton />)
wrapper.find('Like').simulate('click')
expect(wrapper.state().liked).toBe(true)

여기 왜 그래?

오보: (일명 가짜 경보) 보기에는 잘못된 것 같지만 사실은 그렇지 않다.
예를 들어 구성 요소를 재구성하려고 합니다.재구성을 통해 나는 행동이나 계약(도구, 사건...)이 아니라 실현을 바꾸는 것을 가리킨다.그렇지 않으면 재구성이 아니다.liked 를 isLiked 로 이름을 바꾸면 테스트가 실패합니다.그것은 이렇게 해서는 안 된다.문제가 발생했을 때, 우리는 테스트를 작성하는 데 실패했다.아무도 변수명에 관심이 없어요!하지만 행동하면 상황이 달라진다.중요한 것만 테스트해!

가음성: (테스트 통과, 하지만)
우리는 출력을 검증하는 것이 아니라 내부를 검사한다.우리는 출력이 여전히 예상대로 작동하는지 확인할 수 없다.최종 사용자와 같은 방식으로 프로그램을 테스트하지 않았기 때문에 이런 상황이 발생할 수 있다.다시 말하면, 우리 사용자와 다른 이 구성 요소를 사용하려는 개발자들은 구성 요소 내부의 마력에 진정으로 관심을 가지지 않는다.

세부 사항을 피하기 위해 구성 요소를 블랙박스로 간주합니다. 입력과 출력만 테스트합니다.

세부 사항이 없는 동일한 테스트는 다음과 같습니다.

const spy = jest.fn()
const wrapper = mount(<LikeButton onClick={spy}/>)
wrapper.find('Like').simulate('click')

expect(wrapper.prop('aria-label').toEqual('liked')
expect(spy.mock.calls[0][0]).toBe(true)

# 9 - 항상 녹색

나는 몇 년 전에 내가 회사에 가입한 것을 기억한다.첫날, 나는 응용 프로그램을 시작할 수 없었다.조사 결과 누군가가 SQL 파일에서 하나;를 잊어버리고 마스터에게 밀어준 것으로 나타났다.응용 프로그램이 빌어먹을 점수 때문에 파괴되었다.기본 도구를 사용할 때, 이런 문제들은 영원히 발생하지 않을 것이다.
만약 개발자가 드래그 요청을 열기 전에 테스트를 수동으로 실행할 것을 요구한다면, 그것은 작용하지 않을 것입니다.인간은 실수하기 쉽다.이 밖에 이것은 어리석은 일이다.가장 좋은 것은 이 일을 로봇에게 맡기는 것이다. 왜냐하면 로봇은 매우 싸고 거짓말을 하지 않기 때문이다.자동화 작업은 당신의 테스트가 항상 녹색임을 보장할 것입니다.
나는 심지어 나를 믿지 않기 때문에, 나의 모든 보조 항목은 기본적으로 CI를 사용했다.내가 내 코드를 통합하는 유일한 방법은 to open a pull request and get a green build 이다.

#10 - 지표 테스트가 아닌 신뢰 테스트 작성

"When a measure becomes a target, it ceases to be a good measure"

－ Goodhart's law

덮어쓰기 구동 테스트를 많이 봤어요.™️. 그들의 매니저가 이렇게 하라고 요구하거나 GitHub 저장소에'100% 코드 커버율'을 보여주고 싶어하기 때문이다.
내가 보기에 이것은 정말 나쁜 생각이다.다음과 같은 몇 가지 이유가 있습니다.

덮어쓰는 코드가 반드시 테스트하는 코드를 의미하는 것은 아니다.

높은 코드 커버율은 품질 착각을 가져왔다.그러나 당신은 점수를 높이는 것 외에 아무것도 하지 않는 높은 백분율의 상관없는 테스트를 할 수 있다(세부 사항 참조).

Dev가 테스트를 작성하는 것은 자신감을 위한 것이 아니라 하나의 지표를 만족시키기 위한 것이다.

마지막이 중요합니다.문제를 잘못된 쪽에 두었기 때문에, 우리는 왜 테스트를 써야 하는지 잊어버렸다.우리는 모두 자신감 테스트를 써야 한다.설명된 대로 작동하는 배송 코드에 대한 신뢰와 6개월 후 귀하나 동료가 응용 프로그램의 이 부분을 처리할 때 행동은 변하지 않을 것입니다.
모든 코드가 테스트를 필요로 하는 것은 아니다.응용 프로그램의 숨겨진 설정과 지불 페이지에서 같은 수량의 테스트를 기대하는 것은 절대 허튼소리다.창작 테스트는 투자이다.테스트에 표시되는 ROI(투자 수익)가 없으면 건너뜁니다.만약 당신이 라이브러리를 개발하고 있지 않다면.
당신은요, 테스트의 황금 법칙은 무엇입니까?
본문을 읽어 주셔서 감사합니다.🤘. 나는 네가 그것이 유용하다고 생각하길 바란다.만약 당신이 그것을 좋아한다면, 그것을 하나 주십시오❤️ 혹은🦄! 언제든지 아래나 위의 부분에 논평을 발표하거나 문제를 제기해 주십시오.
최초로 maxpou.fr에 출판되었다.