그날 내가 테스트 코드를 거의 완전히 멈춘 이야기를 알려줄게.
이번 주 10번째, CI 실패로 "받은 값이 저장된 스냅샷과 일치하지 않습니다"와 유사한 오류 메시지가 발생했습니다.

<div
  - className="myClassName" >
  + className="myNewClassName" >
  + <div>
    Hello world
  + </div>
</div>

이 테스트를 복구하는 것은 무의미하다. 만약 클래스가 다르거나 내가div 표시를 추가했다면, 왜 이것이 중요합니까?
팀에 스냅샷 업데이트를 읽는 사람이 없기 때문에 복귀를 막지 못했다.
나는 너무 낙담해서 하마터면 컴퓨터를 망가뜨릴 뻔했다. 문을 쾅 닫고 사직할 뻔했다.
하지만 반대로 나는 이런 에너지를 더 적극적인 일로 이끌기로 했다.
나는 프로젝트 테스트가 어떻게 이런 상태에 들어갔는지 생각하기 시작했다.
왜 모든 사람들이 우리가 코드 라이브러리를 테스트해야 한다고 동의하는데, 이렇게 많은 개발자들이 그것을 싫어합니까?
내가 유일하게 낙담한 사람인가?아니오, 없습니다.
사람들이 TDD를 사용한다고 말할 때 나는 그들을 믿지 않는다에밀리 프리만(
)
왜 아무도 이것에 대해 행동을 취하지 않습니까?

악순환 이론이나 인간을 위한 테스트를 어떻게 멈추나요

이것은 나의 이론으로 이런 상황을 해석하는 것이다.
저는'테스트의 악순환'이라고 합니다.™:

개발자가 기능을 변경하는 코드.테스트는 실패했지만 원인은 아직 명확하지 않다.

개발자가 테스트를 복구했습니다.
그들은 왜 테스트가 여기에 있는지 모른다.
그들은 그것을 복구하는 데 시간을 들이는 것은 가치가 없다는 생각에 점차 익숙해졌다.

다음에 이 개발자가 코드를 작성할 때 그들은 더 적은 시간과 정력을 들여 테스트를 작성한다.

복귀...

만약 당신이 이것에 대해 공감대를 형성한다면, 당신은 팀원들이 당신의 의도를 이해하게 하는 것이 아니라 CI를 위해 테스트를 작성하여 그 역할을 발휘하도록 하고 있다.
테스트는 협업 도구로 당신이나 당신의 동료가 실패할 때 테스트를 읽을 수 있습니다.
한 달 안에 그들을 이해할 수 있도록 확보해야 한다. 당신이 해야 할 일을 모두 잊어버리면.

Tests are meant to be read by humans, not your CI.

당신은 어떻게 인류를 위해 테스트를 작성했습니까?
다음은 내가 너에게 준 세 가지 건의이다.

왜: 왜 테스트를 하는지 알아야 돼.테스트는 소프트웨어 공학의 보편적인 진리이기 때문에 왜 프로젝트에서 테스트를 해야 하는지 잊기 쉽다.당신을 격려하는 요소를 찾아라. 그것은 당신이 작성한 테스트를 다른 사람들이 읽도록 인도할 것이다.

뭐: 집중이 필요해.나는 그것을 전부 끝내고 평범하게 하는 것이 아니라 한 가지 일을 잘하는 것이 가장 좋다고 생각한다.테스트할 내용을 선택하고 모든 테스트를 시도하지 마십시오.

어떻게: 목표에 맞는 가장 좋은 도구를 선택하십시오.읽기 및 유지 보수가 가능한 품질 테스트를 작성하는 데 도움이 필요합니다

#1: 왜 테스트를 썼어요?

인간을 위한 테스트는 시간이 필요하고, 당신이 하고 있는 일에 몰입해야 한다.
왜 우수한 테스트를 작성해야 하는지 잘 모르겠다면, 이 정도는 할 수 없습니다.

Do not write tests because you have to. Make sure you and your team know why you write tests.

프로젝트에 품질 도구를 설정할 때 보통 자동 테스트를 제공합니다.
linter와 달리 테스트는 매일 실패하는 것이 아니라 코드의 질에 대한 장기적인 투자이다.
왜 이러는지 잊기 쉬워.
테스트 환경을 설정하기 전에 왜 테스트를 해야 하는지 설명해야 합니다.
장기적으로 볼 때, 당신은 무엇을 얻기를 원합니까?
더 좋은 문서?
더 적은 컴백 오류?TDD의 개발자 체험 도구?
너와 너의 팀은 네가 왜 이러는지 확실히 알아야 한다.엉망진창인 테스트의 악순환에 빠지기 쉬우므로, 왜 테스트를 작성해야 하는지 모두가 알고 있다면, 목표를 벗어날 때 일찌감치 발견할 수 있다.당신의 목표를 명확히 하면 당신의 팀원들이 당신의 테스트에 대해 소유권을 가지게 될 것입니다. 그들은 필요할 때 당신의 개선을 도울 것입니다.

#2: 먼저 테스트해야 할 부품 선택

만약 우리가 나의 프로젝트에서 스냅샷을 사용하도록 선택한다면, 그것은 더욱 빠를 것이다.
우리는 너무 많은 시간이 걸리지 않는 상황에서 모든 코드 라이브러리를 테스트하기를 바란다.
100%의 커버율을 유지하기 위해서, 우리는 기능을 추가할 때마다 유지해야 하는 테스트를 작성하기 시작했다.그들은 우리가 후퇴를 잡는 것을 도울 수 없다. 왜냐하면 그들은 변화가 너무 빈번하기 때문이다.
투자가 아무리 작아도 가치가 없다.

Do not aim for a 100% code-coverage of generic tests, aim for 100% of readable tests

모든 내용을 테스트할 필요가 없습니다.
설정이 코드의 모든 방면에 적합하지 않을 수 있습니다.
나는 항상 논리성이 강한 함수를 위해 단원 테스트를 작성한다.

그것들은 읽기도 어렵고 파괴되기도 쉽다.테스트는 다른 개발자들이 그것을 파괴하지 않도록 확보하는 보호 조치이다.

설치 및 작성 비용이 저렴합니다.

그것은 매우 빠르기 때문에ci를 늦추지 않는다.

그러나 대부분의 코드에 대해 말하자면 이것은 하나의 사건 연구이다.
전방 응용 프로그램의 사용자 체험을 테스트해야 합니까?
만약 내가 복잡한 단일 페이지 응용 프로그램을 작성하고 있다면, 사용자 체험은 매우 발전할 것이다.
테스트는 아마도 나의 가장 중요한 임무일 것이다. 이렇게 하면 나는 후퇴를 방지할 수 있다. 이것은 사용자가 나의 응용 프로그램에 대한 감상에 큰 영향을 미친다.
나는 이 때문에 통합되거나 끝까지 테스트를 작성하고 싶다.
전방 응용 프로그램 인터페이스를 테스트해야 합니까?
만약 내가 공유 구성 요소 라이브러리를 쓰고 있다면, 나는 UI에 중점을 두고 논리적 구성 요소를 가지고 있을 것이다.
나의 첫 번째 임무는 나의 사용자에게 신뢰할 수 있고 일치하는 사용자 인터페이스를 제공하는 것이다.
사용자 체험 논리를 테스트하는 것은 처음부터 이 점을 주목하지 않고 선택할 수 있는 추가적인 장점이다.

#3 올바른 도구 선택

좋은 테스트 도구가 많이 있습니다.
이제 테스트를 작성하는 이유와 코드의 어떤 부분을 주목해야 하는지 알게 되었습니다. 장갑처럼 필요한 도구를 찾을 수 있습니다
다른 항목에서, 나는 React 테스트 라이브러리를 사용하여 나의 전단 React 응용 프로그램을 테스트하기로 선택했다.
도구를 원합니다.

React 응용 프로그램 구성 요소의 논리를 테스트하고 그들이 한 일을 기록합니다

새로운 개발자가 프로젝트를 시작할 때 자신감을 가지도록 도와준다

팀이 바뀌어도 이런 목표에 전념할 수 있도록 도와줄 것이다

이것이 바로 내가react 테스트 라이브러리를 선택하여 그 위에 통합 테스트를 작성하는 이유이다.
이것은 아주 좋은 개발 체험이다.
나도 개인적인 목표가 하나 있다. 바로 이 새로운 도구를 시도하는 것이다. 그것은 매우 좋은 평론이 많다.
컴파일링 테스트를 재미있게 할 수 있는 도구를 찾거나 테스트 구동 개발을 할 수 있는 도구를 찾으려면 이런 방식으로 인간을 위해 테스트를 작성할 수밖에 없다.

준비됐어!

이제 알겠다. 만약 당신이 테스트가 쓸모없다고 생각하거나 유지하는 것이 고통스럽다는 것을 발견한다면, 당신은 테스트의 악순환에 처해 있을 것이다.
이러한 상황에서 벗어나려면 다음 절차를 따르십시오.

테스트는 문서와 협업 도구로 팀에서 유지하고 인류가 읽어야 한다는 것을 기억하라

테스트를 작성한 이유를 팀이 알고 있는지 확인하십시오.
이것은 네가 자랑스러워하는 우수한 테스트를 쓰도록 격려할 것이다.

모든 것을 시도하지 마라.
커버율은 숫자일 뿐 코드 품질의 상징이 아니다.
중점은 모든 부분이 아니라 좋은 부분을 테스트하는 것이다.

사용자에게 적합하고 개발자가 재미있게 체험할 수 있는 도구 선택