단위 테스트 초보자를위한 단위 테스트 모범 사례

최근에는 더 큰 프로젝트 나 작은 도구를 사용하는 사람들을 위해 작은 구성 요소 만 작성했습니다. 나는 단위 테스트를 작성 한 적이 없으며 항상 작성 방법을 배우고 실제로 프로그램을 실행하고 실제 테스트하는 것보다 훨씬 오래 걸리는 것처럼 보입니다.

완성하기까지 몇 개월이 걸리는 상당히 큰 규모의 프로젝트를 시작하려고합니다. 요소를 작성할 때 (항상처럼) 요소를 테스트하려고하지만 단위 테스트로 시간을 절약 할 수 있을지 궁금합니다.

누군가 좋은 조언을 줄 수 있는지 궁금합니다.

1. 프로젝트 시작시 단위 테스트를보고 TDD 방식을 채택해야합니까?
2. 각 섹션이 완료된 후 테스트를 작성해야합니다.
3. 프로젝트를 완료 한 다음 마지막에 단위 테스트를 작성해야합니다.

어떤 사람들은 달리 말하지만 TDD와 단위 테스트를 분리하는 것이 좋습니다. TDD는 상당히 정신적 인 변화이며 단위 테스트는 처음에는 시간이 걸리는 것으로 보입니다. 그것들을 하나의 아이템으로 생각하면 즉시 충분한 이익을 얻지 못할 위험이 있으며 TDD 및 단위 테스트를 단순히 중단하려는 유혹이 있습니다.

먼저 단위 테스트를 작성하는 것입니다. 처음에는 완벽 할 필요는 없습니다. 작은 코드 단위를 테스트하는 방법과 조롱을 사용하여 구성 요소를 격리하는 방법을 스스로에게 알려주십시오.

이것은 가장 큰 타임 테이커이지만 지금까지 가장 큰 보상을 받았습니다. 테스트하려는 웹 페이지에 더 이상 14 개의 웹 페이지를 넘길 필요가 없다는 것을 알게되면 내가 말하는 내용을 알게됩니다.

나를 위해, 큰 유레카 순간은 정규식을 테스트하려고하는 Windows 응용 프로그램이었습니다. 정규식을 테스트하려면 두 가지 양식을 작성해야합니다. NUnit을 설치하고 해당 방법에 대한 테스트를 작성하여 테스트 시간을 얼마나 빨리 절약했는지 확인했습니다. 그런 다음 에지 사례를 처리하기 위해 더 많은 테스트를 추가했습니다. 등등.

그런 다음 단위 테스트 작성을 배우십시오. 많은 개별 테스트를 빠르게 작성하고 작성하는 취성 테스트 간의 균형을 알아 봅니다. 이것은 매우 쉽습니다. 교훈은 이상적으로는 각 테스트마다 한 가지만 테스트하는 것이지만 시간이 오래 걸리는 법을 빨리 배우므로 모든 코드 변경에서 중단되는 테스트를 작성할 때까지 규칙에 약간의 구부림을 시작한 다음 올바른 균형으로 돌아갑니다 (후자보다 전자에 더 가깝습니다).

내가 말했듯이 TDD는 당신이 일하는 방식에있어서 중요한 정신적 변화입니다. 그러나 어쨌든 테스트를 작성하고 나면 개발 프로세스에 많은 시간이 걸리지 않습니다. 그리고 당신은, 당신의 코딩 스타일이 당신의 눈앞에서 개선되는 것을 볼 것이라고 약속합니다. 또는 오히려 당신이 그것을 떨어 뜨리지 않으면 그것은 당신을위한 것이 아닙니다.

마지막으로 염두에 두어야 할 것은 TDD가 단위 테스트에만 국한되지 않는다는 것입니다. 합격 테스트 중심 설계는 TDD의 모든 부분입니다. 그것들을 당신의 마음에 섞이지 않는 또 다른 좋은 이유.

나는 다른 사람들에게 동의합니다 (마지막으로 테스트를 작성하지 마십시오. TDD는 배우는 데 시간이 걸리지 만 테스트를 시작할 수는 있지만 궁극적으로 전체 TDD를 목표로합니다). 그러나 귀하의 의견에 대한 응답으로 한 가지를 추가하고 싶었습니다. "단위 테스트로 시간을 절약 할 수 있는지 궁금합니다."

내 대답은 명백합니다. 테스트없이 비슷한 시간 코딩을 한 후 10 년 전 TDD 방식을 배웠습니다. 요즘 내가 짧고 (<250 loc) 무언가를하거나 간단한 것을하거나한다면 TDD하지 않을 것입니다. 그렇지 않으면 시간이 절약되기 때문에 정확합니다.

시간 절약은 WTF 감소, 디버깅 감소 및 두려움 감소의 세 가지 방식으로 제공됩니다. 첫 번째는 분명합니다. 당신이 지은 것이 무엇을하고 있는지 궁금해하는 데 시간이 덜 걸립니다. 문제가있는 경우 a) 테스트 된 버그를 즉시 포착하고 b) 테스트되지 않은 버그는 숨길 장소가 적기 때문에 디버깅이 훨씬 쉽습니다.

그러나 두려움이 적을수록 더 미묘합니다. TDD 코드베이스에서 시간을 보내기 전까지는 변경 사항에 대해 걱정하는 데 시간이 얼마나 걸리는지조차 알지 못합니다. X가 작동합니까? Y를 깨뜨릴까요? 영향을받을 수있는 Z가 있습니까? TDD를 사용하면 두려움이 테스트로 바뀌고 컴퓨터가 걱정을 자동화하기 때문에 사라집니다. 용감한 개발자는 더 빠른 개발자입니다.

1. 시작할 때 단위를보고 TDD 접근 방식을 채택해야합니다.

2. 각 섹션이 완료된 후 테스트를 작성해야합니다.

이 중 하나이지만 세 번째 옵션은 아닙니다 .

@ pdr이 지적했듯이 적절한 단위 테스트를 배우려면 시간이 걸립니다. 프로젝트 기한이 시작될 때 마감 시간이 끝나는 시점이 아니라 배우는 데 시간을 투자하고 싶을 것입니다. 이렇게하면 이미 프로젝트 속도가 빨라지고 프로젝트 수명주기 초기에 대부분의 버그를 발견했기 때문에 마감일이 가까워 질수록 혜택을 거두기 시작할 수도 있습니다.

첫 번째 단위 테스트는 항상 가장 어렵습니다. 특히 이미 작성된 코드를 테스트하는 경우 특히 그렇습니다. 이러한 코드는 단위 테스트에 적합하지 않을 수 있으므로 테스트에 적합한 상태로 모든 개체를 배선하는 데 어려움을 겪을 수 있습니다. 따라서 첫 번째 단위 테스트 시도에 대해 쉽고 고립 된 저수준 테스트를 선택한 다음 점차적으로 난이도를 높일 수 있습니다. 첫 번째 테스트 픽스처가 준비되면 다음 테스트 케이스가 훨씬 쉬워지고 네 번째 테스트 케이스에 도달 할 때 컨베이어 벨트와 같은 테스트 케이스가 생성됩니다. 그때 코드가 작동 한다는 것을 반복적으로 증명할 수 있다는 장점을 느끼기 시작할 때입니다 ...

저는 개인적으로 TDD 접근 방식을 선호하며 그것이 도전적이라고 생각하지 않습니다. 인내심이 필요하지만, TDD를 빨리 시작할수록 전반적인 단위 테스트의 이점을 더 빨리 볼 수 있다고 생각합니다. 그러나 처음 몇 단위 테스트는 이미 가지고있는 코드를 작성하는 것이 좋습니다. 그런 다음 중단되면 TDD 실험을 시작할 수 있습니다.

초보자가 할 수있는 가장 좋은 방법은 단위 테스트에 적합한 일부 코드 카타를 해결하는 것입니다. 예를 들어; 이메일 주소 확인. 이 Code Katas 중 일부를 다루면 TDD가 자연스러운 흐름이됩니다. 내가 언급 한 이메일 주소 검사기의 다음 코드 kata를 확인하십시오. 이메일 검사기

모르는 사람들을위한 Code Katas가 무엇인지에 대한 설명은 다음 링크를 확인하십시오. Code Katas