제가 일한 최초의 실제 소프트웨어 회사는 단위 테스트 (NUnit)에 관한 것입니다. 그 당시에는 우리가 진짜 고집 스러웠는지 모르겠습니다. 우리의 코드 커버리지가 어떤 것인지 전혀 모르고 대부분의 단위 테스트를 작성했습니다. 그 이후로 많은 테스트를 수행하는 일부 회사를 만났습니다. 그러나 그것은 의자 테스트입니다. 사람에 의존하고 반복성이 낮으며 버그를 잡을 가능성이 낮습니다. 다른 태도는 다음과 같습니다. “미래에”함께 가고 싶었던 것입니다. 기본적으로 돈이 하늘에서 떨어질 때.
단위 테스트가 그리워요. 하지만 새로운 직업을 찾을 때 단위 테스트는 회사가 미래에 “계속 진행”하기를 원하거나 전혀하지 않는 것입니다 (어, 그것은 한동안 존재했습니다 지금!). 지난 2 년 동안 내가 살펴본 작업 요구 사항의 60-75 %가 단위 테스트를 전혀 나열하지 않았다고 말하고 싶습니다. 단위 테스트 경험이있는 한두 명만 (중급 개발자 위치) 요구 사항으로 생각할 수 있습니다.
그래서 질문은 무엇이 빠졌 습니까? 사람들을 더 생산적으로 만든다고 생각하지만, 실제로 그렇게하는 데 상당한 시간을 보낸 후에야합니다. 단위 테스트의 비용 절감에 대한 좋은 연구가 없습니까? 내가보고있는 회사 유형입니까?
편집 : 제목이 약간 악마 지지자이지만, 나는 나 자신을 단위 테스트 지지자라고 생각합니다.
답변
제 경험상 여기에는 몇 가지 요인이 관련되어 있습니다.
- 경영진은 단위 테스트가 실제로 무엇인지, 왜 그것이 실제 내재적 가치를 가지고 있는지 이해하지 못합니다.
- 경영진은 빠른 제품 제공에 더 관심을 갖는 경향이 있으며 단위 테스트가 해당 목표에 역효과를주는 것으로 (잘못) 인식합니다.
- 테스트가 전적으로 QA의 관점에 속한다는 오해가 있습니다. 개발자는 코더이며 테스트를 작성할 수 없습니다.
- 도구를 무료로 사용할 수 있다는 사실에도 불구하고 경영진이 단위 테스트를 올바르게 수행하기 위해 돈을 써야한다는 일반적인 오해가 있습니다. (물론 개발자가 고려할 시간을 늘리는 것이 있지만 실제로 금지되지는 않습니다.)
- Will의 대답은이 대답을 반올림합니다. 테스트 코드의 가치를 결정하는 것은 매우 어렵습니다 (jcollum 편집).
당연히 다른 요소가 있지만 지금까지 내가 겪은 것입니다.
답변
1) 어렵다
2) 시간이 걸린다
3) 테스트 코드의 가치를 결정하는 것이 매우 어렵다
포인트 3은 끈적 거리는 것입니다. 좋은 단위 테스트는 버그를 줄입니다. 그러나 좋은 프로덕션 코드도 마찬가지입니다. 단위 테스트로 인해 존재하지 않는 버그 수를 어떻게 확인합니까? 존재하지 않는 것을 측정 할 수 없습니다. 연구를 가리킬 수는 있지만 비즈니스 관리자의 스프레드 시트에는 적합하지 않습니다.
답변
모든 책임을 “관리”에 두는 것은 쉽습니다. 그러나 경영진이 정말로 단위 테스트를하지 말라고 말하고 있습니까?
일반적으로 관리는 모듈화, 추상 데이터 유형, 디자인 패턴 또는 단위 테스트 등 작업 수행 방법을 알려주지 않습니다. 이들은 성공적이고 유능한 소프트웨어 엔지니어가 적용하는 거래 도구이지만 열악한 엔지니어는 적용하지 않습니다.
귀하의 질문에 대한 진정한 답은 단위 테스트가 정말 어렵고 컴퓨터 과학 학생들은 이에 대한 훈련을받지 않았다는 것입니다.
자신 만의 문자열 클래스를 작성할 때 쉽습니다. 실제 제품을 테스트 할 때 파워 포인트 슬라이드에서 아무도 말하지 않은 문제에 직면하게됩니다.
- 사용자 상호 작용. 애플리케이션의 절반은 사용자 인터페이스 로직입니다. 버튼을 움직여도 분해되지 않는 자동화 된 방식으로 어떻게 테스트합니까?
- 외부 API 및 프레임 워크와의 상호 작용. Windows 커널 드라이버를 작성하는 경우 어떻게 단위 테스트합니까? 사용하는 모든 IRP 및 커널 기능에 대한 스텁을 작성하여 효과적으로 OS 커널 시뮬레이션을 생성합니까?
- 네트워크 통신은 21 세기의 것입니다. 여러 분산 구성 요소로 구성된 단위 테스트를 어떻게 조정합니까?
- 좋은 테스트 케이스를 어떻게 선택합니까? 나는 일반적으로 사람들이 “1000 번의 반복 루프에서 임의의 작업을 수행하고 중단되는지 확인”접근 방식을 시도하는 것을 봅니다. 이렇게하면 노력이 수익보다 높고 중요한 버그가 누락되고 단위 테스트가 중단됩니다.
- 성능 요구 사항이 충족되는지 어떻게 테스트합니까?
- 테스트의 패턴에 대한 지식은 거의 없습니다. 스텁, 미리 준비된 답변, 회귀 테스트는 대부분의 사람들이 모르는 개념입니다. 직장에서 실제로 단위 테스트에 대한 책을 읽은 사람은 몇 명입니까?
우리가 관리를 비난 할 수있는 한 가지는 요구 사항 사양에 결과물의 품질 수준에 대한 요구 사항이 거의 포함되지 않는다는 것입니다.
다음에 상사가 예상 시간을 요구할 때 단위 테스트 작성 시간을 포함하고 어떤 일이 발생하는지 확인하십시오.
답변
대부분의 테스트는 아무것도 테스트하지 않습니다.
fileopen () 함수와 파일이 존재하지 않으면 실패하고 파일이 존재하면 성공하는 unittest를 작성합니다. 큰! 이제 BIG5 중국어의 파일 이름으로 작동하는지 확인 했습니까? NFS 공유에 있습니까? USB 키에있는 파일과 UAC가 켜져있는 Vista에서
문제는 함수를 작성한 동일한 프로그래머가 동일한 수준의 기술로 동일한 가정에 따라 단위 테스트를 작성한다는 것입니다. 실제로 작동하려면 다른 사람이 테스트를 작성해야하며 코드를 보지 않고 게시 된 사양에 대해서만 작성해야합니다. -대부분의 회사에서 사양을 작성하는 것만으로도 돌파구가 될 것입니다!
단위 테스트는 개별 함수 코드의 오류를 확인합니다. 입력 / 출력이 잘 알려져 있고 내부 구조가 복잡하지만 많은 경우 시간 낭비 일 뿐인 데이터 액세스 레이어, 수학 라이브러리 등에서 작동 할 수 있습니다.
오류가 코드의 다른 부분 또는 OS 및 사용자와의 상호 작용으로 인한 경우 실패합니다. 높은 / 낮은 DPI 설정이 대화 상자를 엉망으로 만들거나 ‘.’를 바꾸는 외국어 설정과 같은 문제 및 ‘,’는 일반적으로 발견되지 않습니다.
답변
단위 테스트의 ROI에 대한 연구가 수행되었습니다 . 이 질문을 참조하십시오 .
답변
단위 테스트에 관심이없는 개발자를 많이 찾았습니다. 당신이 시작할 때 그것은 항상 적은 보수로 많은 일처럼 보입니다. 아무도 추가 작업에 등록하기를 원하지 않으므로 저항합니다. 일단 사람들이 시작하면 보통 열정적으로 고수하지만 시작하는 것은 어려울 수 있습니다.
답변
단위 테스트의 채택 문제를 제외하고, 단위 테스트는 일반적으로 적절하다고 생각하지만 항상 가치가있는 것은 아닙니다. 단위 테스트가 열악한 구성에 취약하지 않도록 보호하는 특별한 것은 없습니다.
단위 테스트에는 비용 (생성, 유지 관리 및 실행)이 있으며 해당 비용보다 더 큰 이점을 제공하는 경우에만 가치가 있습니다. 테스트 생성은 다른 기술과 마찬가지로 성공을 위해 특정 경험과 지식이 필요합니다. 충분한 경험이 없으면 다른 경험이있는 개발자라도 가치가없는 낮은 품질, 낮은 가치 및 / 또는 높은 비용의 단위 테스트를 만드는 것은 매우 쉽습니다. 특히 단위 테스트의 가치를 판단하는 것이 얼마나 어려운지를 감안할 때.
또한 단위 테스트는 코드 품질을 향상시키는 한 가지 방법 일뿐 아니라 유일한 방법은 아닙니다. 상황에 따라 일부 팀에서는 소프트웨어 품질을 높이는 가장 효과적인 방법이 아닐 수 있습니다.
단위 테스트에 많은 노력을 기울이는 것이 소프트웨어 품질을 보장하는 것은 아닙니다. 또한 단위 테스트 없이도 최고 품질의 소프트웨어를 생산할 수 있습니다.
