테스트되지 않은 코드는 무엇입니까? 당신이 통제할 수 없는 복잡한 상황을 다루는 코드인가? 스레드, 실행 중인 명령, 자식, 네트워킹 또는 UI?
우리 앱은 복잡할 때 가장 흥미롭습니다. 그들은 또한 가장 위험합니다. 그래서 테스트하기 어려운 코드가 바로 잘 테스트해야 하는 종류의 코드입니다. 항상 그런 것은 아닙니다.
대신 해당 코드를 터치할 때마다 가볍게 터치합니다. 당신은 조심스럽게 밟습니다. 아마도 당신은 수동 테스트를 할 것입니다. 그리고 풀 리퀘스트를 보낼 때 팀원들이 이러한 테스트가 존재하지 않는다는 것을 깨닫지 않기를 바랍니다.
하지만 그렇다고 해서 상황이 나아지는 것은 아닙니다. 다음 번에 같은 문제, 같은 버그, 같은 스트레스에 직면하게 될 것입니다. 어떻게 그 어려운 테스트를 신뢰할 수 있는 것으로 만들 수 있습니까?
생각의 전환
이 테스트에서 가장 실망스러운 점은 무엇입니까? 원하는 대로 쓰려면 10배의 시간이 걸릴 것입니다. 테스트를 작성하는 데 소비한 시간에 비해 테스트에서 절약한 시간을 추정한다면 가치가 없어 보입니다.
하지만 이 테스트만 있는 것은 아닙니다. 미래의 모든 테스트에 관한 것입니다. .
내가 본 대부분의 테스트를 거친 코드는 많은 지원을 받았습니다. test/models의 코드만이 아닙니다. . 매우 잘 테스트된 코드에는 가짜가 있고, 모의가 있으며, 좋은 테스트 설비 세트가 있으며, 테스트를 위한 구성 옵션이 있습니다.
이 모든 것을 작성하고 정리하는 데 시간이 걸립니다.
하지만 일단 가지고 있으면 너무 좋습니다. 테스트 후 테스트를 수행하고 코드에 대해 편안함을 느끼며 투자한 후 신속하게 이동할 수 있다는 확신을 가질 수 있습니다.
의지할 수 있습니다. 당신이 이미 한 일에 대해.
따라서 복잡한 코드에서 버그를 방지하는 것만이 아닙니다. 미래의 코드를 하나씩 테스트하기 쉽게 만드는 것입니다.
통합 테스트로 만들기(현재)
그러나 때로는 가치를 이해하는 것이 아니라 이해합니다. 대신, 작고 빠른 단위 테스트를 작성하는 방법을 알 수 없기 때문에 막혔습니다.
실제로 git를 실행하지 않고 배포 도구에서 올바른 git 명령을 실행하고 있는지 어떻게 알 수 있습니까? ? 원격 서버에 올바른 헤더를 보내고 있는지 어떻게 확인합니까?
시간이 충분하면 테스트에 사용할 고품질 가짜를 만들 수 있습니다.
하지만 생각하기에 너무 많은 것 같을 때 시도할 수 있는 다른 것이 있습니다. 테스트를 '코드 테스트'와 '모의 작성'의 두 단계로 나눕니다.
해당 서버를 호출하면 됩니다. 해당 명령을 실행하면 됩니다. 왜?
- 시작하기가 훨씬 쉽습니다. 당신은 아마 그 명령을 수동으로 테스트하고 있을 것입니다. 맞죠? 콘솔에서 실행하시겠습니까, 아니면 브라우저에서 실행하시겠습니까? 테스트에 복사하기만 하면 됩니다.
- 모의 또는 가짜를 작성하면 이 테스트를 사용하여 모의가 제대로 작동하는지 확인할 수 있습니다. 가짜에서 보는 것과 같은 행동을 실제 세계에서 본다면 가짜가 좋을 것입니다!
하지만 이러한 테스트를 영원히 유지하고 싶지는 않을 것입니다.
- 통합 테스트가 가지고 있는 모든 문제를 가지고 있습니다. 그들은 느릴 수 있습니다. 라이브 인터넷 연결이 필요할 수 있습니다. 앱이 실제로 신경 쓰지 않는 동작에 의존하기 때문에 깨지기 쉽습니다.
- 실제 환경에서는 테스트하지 못할 수도 있습니다. 예를 들어, 다른 쪽에서 서버를 제어하지 않을 때 특정 오류 코드를 어떻게 강제 적용합니까?
- 사용하는 서버에 의해 차단되어 테스트(및 앱)가 중단될 수 있습니다. 이것은 실제로 제게 일어났고 큰 문제였습니다.
따라서 실제 통합 테스트로 테스트를 작성하는 것은 영구적인 솔루션이나 장기적인 솔루션이 아닙니다. 그러나 이러한 모든 단점에도 불구하고 여전히 유용합니다. 교체한 후에도 통합 테스트를 별도의 제품군에 보관할 수 있습니다. 그렇게 하면 가정이 아닌 현실과 비교하여 내 코드를 항상 확인할 수 있습니다.
일부 코드는 테스트하기 어렵습니다. 신뢰할 수 있는 테스트를 빠르게 작성하는 데 필요한 인프라를 구축하는 데 시간이 걸립니다. 그리고 대부분의 경우 가치가 없어 보입니다.
하지만 단일 테스트에 대한 생각을 멈추고 미래의 모든 테스트를 더 쉽게 만드는 가치에 대해 생각하면 복잡한 코드를 테스트하는 것이 훨씬 더 동기 부여가 됩니다. 그리고 첫 번째 테스트가 끝나면 나머지 테스트는 마법처럼 훨씬 쓰기 쉬워지는 것 같습니다.
하지만 때로는 충분하지 않습니다. 코드가 실제 세계에서 작동하는지 확인하는 방법을 알고 있지만 테스트 방법을 알 수 없다면 어떻게 될까요?
그런 일이 발생하면 테스트를 순수하고 고립된 상태로 유지해야 하는 것으로 보지 마십시오. 대신 수동으로 이미 하고 있는 작업을 자동으로 수행하는 방법으로 간주합니다.
완벽하지 않으므로 가능한 한 빨리 교체해야 합니다. 그러나 이러한 테스트를 통해 복잡한 코드를 빠르게 작성하고 변경하는 데 필요한 자신감을 얻을 수 있습니다.