단위 테스트가 그렇게 훌륭하다면 왜 더 많은 회사에서 수행하지 않습니까? [닫은]

제가 일한 최초의 실제 소프트웨어 회사는 단위 테스트 (NUnit)에 관한 것입니다. 그 당시에는 우리가 진짜 고집 스러웠는지 모르겠습니다. 우리의 코드 커버리지가 어떤 것인지 전혀 모르고 대부분의 단위 테스트를 작성했습니다. 그 이후로 많은 테스트를 수행하는 일부 회사를 만났습니다. 그러나 그것은 의자 테스트입니다. 사람에 의존하고 반복성이 낮으며 버그를 잡을 가능성이 낮습니다. 다른 태도는 다음과 같습니다. "미래에"함께 가고 싶었던 것입니다. 기본적으로 돈이 하늘에서 떨어질 때.

단위 테스트가 그리워요. 하지만 새로운 직업을 찾을 때 단위 테스트는 회사가 미래에 "계속 진행"하기를 원하거나 전혀하지 않는 것입니다 (어, 그것은 한동안 존재했습니다 지금!). 지난 2 년 동안 내가 살펴본 작업 요구 사항의 60-75 %가 단위 테스트를 전혀 나열하지 않았다고 말하고 싶습니다. 단위 테스트 경험이있는 한두 명만 (중급 개발자 위치) 요구 사항으로 생각할 수 있습니다.

그래서 질문은 무엇이 빠졌 습니까? 사람들을 더 생산적으로 만든다고 생각하지만, 실제로 그렇게하는 데 상당한 시간을 보낸 후에야합니다. 단위 테스트의 비용 절감에 대한 좋은 연구가 없습니까? 내가보고있는 회사 유형입니까?

편집 : 제목이 약간 악마 지지자이지만, 나는 나 자신을 단위 테스트 지지자라고 생각합니다.

제 경험상 여기에는 몇 가지 요인이 관련되어 있습니다.

1. 경영진은 단위 테스트가 실제로 무엇인지, 왜 그것이 실제 내재적 가치를 가지고 있는지 이해하지 못합니다.
2. 경영진은 빠른 제품 제공에 더 관심을 갖는 경향이 있으며 단위 테스트가 해당 목표에 역효과를주는 것으로 (잘못) 인식합니다.
3. 테스트가 전적으로 QA의 관점에 속한다는 오해가 있습니다. 개발자는 코더이며 테스트를 작성할 수 없습니다.
4. 도구를 무료로 사용할 수 있다는 사실에도 불구하고 경영진이 단위 테스트를 올바르게 수행하기 위해 돈을 써야한다는 일반적인 오해가 있습니다. (물론 개발자가 고려할 시간을 늘리는 것이 있지만 실제로 금지되지는 않습니다.)
5. Will의 대답은이 대답을 반올림합니다. 테스트 코드의 가치를 결정하는 것은 매우 어렵습니다 (jcollum 편집).

당연히 다른 요소가 있지만 지금까지 내가 겪은 것입니다.

1) 어렵다
2) 시간이 걸린다
3) 테스트 코드의 가치를 결정하는 것이 매우 어렵다

포인트 3은 끈적 거리는 것입니다. 좋은 단위 테스트는 버그를 줄입니다. 그러나 좋은 프로덕션 코드도 마찬가지입니다. 단위 테스트로 인해 존재하지 않는 버그 수를 어떻게 확인합니까? 존재하지 않는 것을 측정 할 수 없습니다. 연구를 가리킬 수는 있지만 비즈니스 관리자의 스프레드 시트에는 적합하지 않습니다.

모든 책임을 "관리"에 두는 것은 쉽습니다. 그러나 경영진이 정말로 단위 테스트를하지 말라고 말하고 있습니까?

일반적으로 관리는 모듈화, 추상 데이터 유형, 디자인 패턴 또는 단위 테스트 등 작업 수행 방법을 알려주지 않습니다. 이들은 성공적이고 유능한 소프트웨어 엔지니어가 적용하는 거래 도구이지만 열악한 엔지니어는 적용하지 않습니다.

귀하의 질문에 대한 진정한 답은 단위 테스트가 정말 어렵고 컴퓨터 과학 학생들은 이에 대한 훈련을받지 않았다는 것입니다.

자신 만의 문자열 클래스를 작성할 때 쉽습니다. 실제 제품을 테스트 할 때 파워 포인트 슬라이드에서 아무도 말하지 않은 문제에 직면하게됩니다.

• 사용자 상호 작용. 애플리케이션의 절반은 사용자 인터페이스 로직입니다. 버튼을 움직여도 분해되지 않는 자동화 된 방식으로 어떻게 테스트합니까?
• 외부 API 및 프레임 워크와의 상호 작용. Windows 커널 드라이버를 작성하는 경우 어떻게 단위 테스트합니까? 사용하는 모든 IRP 및 커널 기능에 대한 스텁을 작성하여 효과적으로 OS 커널 시뮬레이션을 생성합니까?
• 네트워크 통신은 21 세기의 것입니다. 여러 분산 구성 요소로 구성된 단위 테스트를 어떻게 조정합니까?
• 좋은 테스트 케이스를 어떻게 선택합니까? 나는 일반적으로 사람들이 "1000 번의 반복 루프에서 임의의 작업을 수행하고 중단되는지 확인"접근 방식을 시도하는 것을 봅니다. 이렇게하면 노력이 수익보다 높고 중요한 버그가 누락되고 단위 테스트가 중단됩니다.
• 성능 요구 사항이 충족되는지 어떻게 테스트합니까?
• 테스트의 패턴에 대한 지식은 거의 없습니다. 스텁, 미리 준비된 답변, 회귀 테스트는 대부분의 사람들이 모르는 개념입니다. 직장에서 실제로 단위 테스트에 대한 책을 읽은 사람은 몇 명입니까?

우리가 관리를 비난 할 수있는 한 가지는 요구 사항 사양에 결과물의 품질 수준에 대한 요구 사항이 거의 포함되지 않는다는 것입니다.

다음에 상사가 예상 시간을 요구할 때 단위 테스트 작성 시간을 포함하고 어떤 일이 발생하는지 확인하십시오.

대부분의 테스트는 아무것도 테스트하지 않습니다.
fileopen () 함수와 파일이 존재하지 않으면 실패하고 파일이 존재하면 성공하는 unittest를 작성합니다. 큰! 이제 BIG5 중국어의 파일 이름으로 작동하는지 확인 했습니까? NFS 공유에 있습니까? USB 키에있는 파일과 UAC가 켜져있는 Vista에서

문제는 함수를 작성한 동일한 프로그래머가 동일한 수준의 기술로 동일한 가정에 따라 단위 테스트를 작성한다는 것입니다. 실제로 작동하려면 다른 사람이 테스트를 작성해야하며 코드를 보지 않고 게시 된 사양에 대해서만 작성해야합니다. -대부분의 회사에서 사양을 작성하는 것만으로도 돌파구가 될 것입니다!

단위 테스트는 개별 함수 코드의 오류를 확인합니다. 입력 / 출력이 잘 알려져 있고 내부 구조가 복잡하지만 많은 경우 시간 낭비 일 뿐인 데이터 액세스 레이어, 수학 라이브러리 등에서 작동 할 수 있습니다.
오류가 코드의 다른 부분 또는 OS 및 사용자와의 상호 작용으로 인한 경우 실패합니다. 높은 / 낮은 DPI 설정이 대화 상자를 엉망으로 만들거나 '.'를 바꾸는 외국어 설정과 같은 문제 및 ','는 일반적으로 발견되지 않습니다.

단위 테스트의 ROI에 대한 연구가 수행되었습니다 . 이 질문을 참조하십시오 .

단위 테스트에 관심이없는 개발자를 많이 찾았습니다. 당신이 시작할 때 그것은 항상 적은 보수로 많은 일처럼 보입니다. 아무도 추가 작업에 등록하기를 원하지 않으므로 저항합니다. 일단 사람들이 시작하면 보통 열정적으로 고수하지만 시작하는 것은 어려울 수 있습니다.

단위 테스트의 채택 문제를 제외하고, 단위 테스트는 일반적으로 적절하다고 생각하지만 항상 가치가있는 것은 아닙니다. 단위 테스트가 열악한 구성에 취약하지 않도록 보호하는 특별한 것은 없습니다.

단위 테스트에는 비용 (생성, 유지 관리 및 실행)이 있으며 해당 비용보다 더 큰 이점을 제공하는 경우에만 가치가 있습니다. 테스트 생성은 다른 기술과 마찬가지로 성공을 위해 특정 경험과 지식이 필요합니다. 충분한 경험이 없으면 다른 경험이있는 개발자라도 가치가없는 낮은 품질, 낮은 가치 및 / 또는 높은 비용의 단위 테스트를 만드는 것은 매우 쉽습니다. 특히 단위 테스트의 가치를 판단하는 것이 얼마나 어려운지를 감안할 때.

또한 단위 테스트는 코드 품질을 향상시키는 한 가지 방법 일뿐 아니라 유일한 방법은 아닙니다. 상황에 따라 일부 팀에서는 소프트웨어 품질을 높이는 가장 효과적인 방법이 아닐 수 있습니다.

단위 테스트에 많은 노력을 기울이는 것이 소프트웨어 품질을 보장하는 것은 아닙니다. 또한 단위 테스트 없이도 최고 품질의 소프트웨어를 생산할 수 있습니다.

글쎄, 우리 회사는 TDD 또는 단위 테스트를 사용하지 않았습니다. 솔직히 말해서 어떻게해야할지 모르겠습니다. 우리는 CapitalizeString () 등과 같은 어리석은 함수에 대해 분명히 할 수 있지만 복잡한 객체가있는 매우 복잡한 시스템에 대해 수행하는 방법을 모릅니다. 또한 인터뷰에 응한 대부분의 사람들은 경험이 없거나 제한적입니다. 단위 테스트는 SO 군중에서 큰 것으로 보이지만 사용 가능한 작업 풀에서는 특별히 크지 않습니다.

TDD는 별도의 주제입니다. 우리는 TDD에 도덕적으로 반대합니다. 우리는 카우보이 코더는 아니지만 이것이 프로젝트의 창의성과 유연성을 저해한다고 믿습니다. 또한 단위 테스트 기능을 작성한 코더가 있다는 것은 의미가 없습니다. 내가 뭔가를 할 때, 나는 내가 생각할 수있는 모든 엣지 케이스로 코딩한다. 내가 필요로하는 것은 내가 놓쳤을 수도있는 것들을 찾기위한 또 다른 두뇌입니다. 우리는 그것을 가지고 있지 않습니다. 팀은 작고 독립적입니다.

요컨대, 우리는 TDD를 믿지 않지만 단위 테스트를 원합니다. 우리는 그렇게 할 경험이 없으며 쉽게 찾을 수 없습니다.

모범 사례에 따라 실제로 아무것도하지 않는 회사가 많이 있습니다. 코드 리뷰도, 단위 테스트도, 테스트 계획도, 아무것도 없습니다.

지속적 통합 플랫폼을 사용하고 단위 테스트를 개발할 수있는 기회로 삼으십시오! 힘을 높이는 동시에 코드의 품질과 안정성을 높이는 쉬운 방법

편집 : 이유는 그들이 CI 및 단위 테스트를 매우 쉽게 만드는 현재 도구를 알지 못한다고 생각합니다.

게으름이 잘못된 단위 테스트의 근본 원인이라고 생각하지 않습니다. 우리 회사의 경우 시간 제약과 "완성"태도는 단위 테스트를 수행하는 데 가장 큰 방해 요소입니다. 또한 시스템이 실패하는 곳은 "단위 수준"이 아니라 통합 수준 (서비스, 데이터베이스 액세스, 테스트를 위해 특정 데이터가 필요한 복잡한 쿼리)에 더 가깝습니다. 이러한 것들은 테스트하기가 더 어렵고 기능을 수행 할 시간이 거의 없다면 유용한 테스트를 동시에 수행 할 시간이 없을 것입니다.

단위 테스트는 컴파일러와 마찬가지로 코드 개발 워크 플로의 자연스러운 부분이어야합니다.

그러나이를 위해서는 단위 테스트의 이점에 대해 경영진을 교육해야합니다. 그러나 주니어 개발자는 그러한 영향을 미칠 가능성이 상대적으로 낮습니다. 따라서 회사가 단위 테스트를지지하는지 여부는 단위 테스트를 옹호하는 수석 개발자 또는 아키텍트가 있는지 여부에 따라 다릅니다.

나는 이것이 "누락 된 것이 무엇이고 왜 더 많은 회사가 단위 테스트를하지 않는가"라는 질문에 대한 답이라고 생각합니다 . :-)

이미 언급 한 몇 가지의 조합 일 것입니다. TDD의 비용 절감을 측정하기가 어렵습니다. IT를 아웃소싱하려는 경우, 직원이있는 직원에 대해 연간 지불하는 비용과 계약 비용을 보여줄 수 있습니다. 매우 구체적입니다. "오,이 테스트에서 버그가 발견되었는데 디버그 및 수정에 4 시간이 걸렸습니다 ..."?

일부 장소에서 사용하지 않는 이유는 단순히 시작하고 계속하는 데 많은 작업이 필요하기 때문입니다. 단위 테스트를 작성하는 데 실제 기능을 작성하는 것만 큼 많은 시간이 걸린다는 사실은 개발자의 생산성을 절반으로 줄이는 것과 같은 일부 관리자에게 보입니다.

또한 팀 (또는 누군가)을 구축하여 인프라를 제자리에 배치하고 유지 관리해야합니다.

로 그리고 앨런이 말한다, 많은 장소는 단순히 모범 사례를 사용하지 않는 - 그들은 단지 가시적 인 무언가를보고 싶어요.

내가 본 바에 따르면 많은 회사가 실제로 단위 테스트가 불가능한 거대하고 고도로 결합 된 코드 기반을 가지고 있습니다. 그들은 또한 적절한 테스트 가능한 요구 사항이 없기 때문에 단위 테스트는 "구축 된"사실상의 요구 사항에 대해 테스트합니다.

프로그래머는 그냥 시작해야한다고 생각합니다. 시작하기위한 몇 가지 간단한 테스트는 개발의 일부로 정당화하기 쉽습니다.

단위 테스트와 같은 것은 빠른 디버깅을 위해 거의 항상 필요합니다. 올바른 입력을 정렬하고, 디버거 중단 점을 설정하고, 애플리케이션을 시작하는 것보다 테스트를 시작하는 것이 얼마나 빠른지 설명하십시오.

코드에 테스트를 문서화하십시오. 테스트의 위치와 실행 방법을 설명하는 주석을 넣으십시오. 미래의 프로그래머는 그것을 보게 될 것이며, 테스트가 확산되기를 바랍니다!

단위 테스트는 대부분의 사람들이 들어 본 블랙 박스 용어 중 하나이지만 단위 테스트를 정확히 구성하는 것이 무엇인지, 어디서 시작해야하는지, 작성하는 방법, 실제로 테스트를 실행하는 방법, 정확히 무엇을 테스트해야하는지 등을 모릅니다. . 등.

많은 경우, 불확실한 개발자가 단순히 "엔터프라이즈 수준 개발자"에게만 필요한 장식이나 불필요한 것으로 무시하는 것이 더 쉽습니다.

저는 단위 테스트의 열렬한 팬이며 다양한 클라이언트 유형을위한 계약 개발 프로젝트를 수행하는 회사의 파트너이기도합니다. 한 달 안에 다양한 크기의 3 ~ 4 개의 프로젝트를 다루겠습니다.

프로젝트가 일회성으로 보일 것 같으면 단위 테스트가 내 비즈니스에 도움이되지 않기 때문에 단위 테스트에 크게 투자하지 않을 것입니다. 이러한 유형의 프로젝트에서는 불확실하거나 익숙하지 않거나 자주 변경 될 수있는 항목 (예 : 내가 제어하지 않는 데이터 소스에 대한 파서)을 단위 테스트 할 것입니다.

내가 알고있는 무언가를 구축하는 경우 수명이 길고, 더 큰 작업이며, 여러 번 반복하여 작업하거나, 오류가 발생하면 클라이언트에게 큰 영향을 미칠 것입니다. , 나는 더 많은 단위 테스트에 투자 할 것입니다. 다시 테스트의 우선 순위는 불확실하거나 익숙하지 않거나 변경되는 코드를 중심으로합니다.

단위 테스트는 작업의 복잡성과 성과가 있을지 여부를 중심으로 진행되어야한다고 생각합니다. 사용되지 않을 추가 코드를 작성하는 것은 의미가 없습니다.

내 경험상 그것은 실제로 당신이 작성하는 소프트웨어에 달려 있습니다. UI에 대한 단위 테스트를 작성하는 것이 매우 어렵다는 것을 알았습니다. 나는 명확한 인 / 아웃이있는 시스템 부분에 대해서만 단위 테스트를 사용합니다.

단위 테스트가 그리워요.

이것은 회사가 단위 테스트를 채택 할 충분한 이유 가 아닙니다 .

충분한 이유는 "저렴"(및 / 또는 "더 나은") 일 수 있습니다. 이는 단위 테스트에 대해 증명하기가 쉽지 않습니다.

유일한 좋은 이유는 "단위 테스트를 작성하는 것이 개발자의 시간을 최대한 활용하는 것"일 수 있습니다. 이는 IMO를 증명하기가 정말 어렵습니다. 어떤 곳에서는 사실 일 수 있습니다. 일부 소프트웨어에서는 일부 개발자에게는 사실 일 수 있지만 다른 곳에서는 사실이 아닐 수 있습니다.

단위 테스트의 세계를 생각하지 않는 개발자가 많이 있습니다. 다른 형태의 테스트 (예 : 자동화 된 통합 / 기능 테스트)가 더 저렴하고 가치가 있다고 생각하는 개발자도 있습니다. 단위 테스트를 좋아합니까?

물론 이상적인 세계에서는 단위 테스트에 반대 할 수 없습니다.

그러나 단위 테스트 작성 여부는 다음과 같은 여러 가지에 따라 달라집니다.

• 소프트웨어 사용 방법. 자신만을위한 소프트웨어를 작성하고 있다면 단위 테스트를 작성 하시겠습니까? 아마 아닐 것입니다. 상업적으로 판매 할 사전 패키지 소프트웨어를 작성하고 있다면 아마도 그렇습니다.

• 얼마나 많은 사람들이 코드를 유지하고 있는지 .... 당신 만 있다면, 코드를 빠르게 실행하는 것만으로도 문제가 없는지 확인하기에 충분하다는 변경을 한 후 충분히 확신 할 수있을 것입니다. 원래 코드를 작성하지 않은 다른 사람들이 이제 코드를 유지해야한다면 단위 테스트를 통해 코드를 업데이트하여 큰 문제를 수정할 때 (분명히 단위 테스트에서 캡처되지 않은) 어떤 것도 깨뜨리지 않았 음을 확신 할 수 있습니다. .

• 코드 복잡성 : 테스트가 필요한 테스트 코드 만. 한 줄 변수 할당 방법은 테스트가 필요하지 않습니다. 여러 실행 경로가있는 50 줄 메서드는 아마도 가능합니다.

• 상업적 상업적 고려 사항 : 사실 단위 테스트를 작성하는 것은 그렇게하지 않는 것보다 오래 걸립니다. 상업적 미래가 불확실한 프로토 타입 소프트웨어를 작성하고 있다면, 코드를 빨리 만드는 것, 지금은 충분히 잘 작동하는 것, 더 잘 작동하는 단위 테스트 코드를 2 주 만에받는 것 사이에는 보상이 있습니다. 때로는 소프트웨어가 짧은 선반을 갖고 다음 프로젝트로 넘어갈 지 여부를 신속하게 파악 (소비자 선호도)하는 것이 좋습니다.

다른 사람들이 지적했듯이 테스트는 그것을 작성한 사람만큼 좋습니다.

주된 이유는 많은 개발자와 개발 관리자가 단위 테스트가 존재하는지 또는이를 사용하는 방법에 대한 단서가 없기 때문입니다.

두 번째 이유는 이미 일부 품질 표준을 충족하는 코드에서만 단위 테스트를 합리적인 방식으로 사용할 수 있다는 것입니다. 일부 기존 코드베이스가 해당 범주에 속하지 않을 가능성이 있습니다.

세 번째 이유는 게으름 및 / 또는 저렴함입니다.

단위 테스트는 테스트 가능한 코드를 작성하는 경우에만 유용하기 때문입니다. 그리고 테스트 가능한 코드를 작성하는 것은 어렵습니다. 그리고 사람들은 게 으르거나 싸다.

편집 : "게으른 및 / 또는 저렴"으로 미묘한 "게으른"; 드물게 사람들은 실제로 기술과 능력이 있고 테스트를 작성할 의향이 있지만 수익에 더 직접적인 영향을 미치는 다른 작업이 있습니다.

문제의 일부는 개발자들이 비즈니스 사람들이 동일한 가치를 가지기를 기대하고 "단위 테스트를해야할까요?"에 대한 답에 정말로 신경을 쓴다는 것입니다. 우리는 어셈블리 언어가 아닌 고급 언어를 사용하도록 사전에 비즈니스로부터 승인을받지 않습니다. 일반적으로 작업을 완료하는 합리적인 방법 일뿐입니다.

요점은 우리 가 전화를 걸 자격이있는 유일한 사람이라는 것입니다 (우리 모두가 주제에 대해 동일한 지식을 가지고 있다고 말하는 것은 아닙니다). 또한 팀이 정책 상 단위 테스트 (또는 오늘의 방법 이름 지정)를 수행하지 않더라도 일반적으로 수행 할 수 없다는 의미는 아닙니다 .

진실은 우리가 너무 세분화하여 수행하는 대부분의 작업에 대한 ROI를 실제로 증명할 수 없다는 것입니다. 왜 단위 테스트가이 비합리적 / 비 전형적인 증명 표준에 부합하는지는 나를 넘어선 다 ...

사람들은 게으르고 강제 될 때만 변화를 받아들입니다.

내 2 센트 :

• 약간의 교육과 훈련이 필요하지만 새로운 졸업생은 이미 적절한 지식을 갖추고 있습니다.
• 더 나은 도구를 사용하면 테스트 오버 헤드를 줄일 수 있으며 이러한 문제도 발생합니다 (리팩토링 등).

그래서 그것은 시간 문제입니다.

Bob Martin이 다음과 같이 주장하는 Martin-Coplien 논쟁이 있습니다.

"현재 개발자가 단위 테스트에서 실행하지 않은 코드 라인을 제공하는 것은 무책임합니다."

[ http://www.infoq.com/interviews/coplien-martin-tdd]

테스트에서 모든 사람을 판매하려면 다음을 수행하십시오.

1. 여러 테스트를 작성하십시오.
2. 코드를 변경하고 테스트에 실패한 다른 개발자에게 알립니다.
3. 그들은 코드를 수정할 것입니다.
4. 이제 특정 버그없이 릴리스 할 수 있습니다.

관리자조차도 이것을 이해할 수 있습니다.

많은 웹 사이트가 제대로 작성되지 않은 것과 같은 이유로 기업은 단위 테스트를 수행하지 않습니다. 무지와 사람들은 오래된 습관을 고수합니다. 우리 회사에서는 단위 테스트 (Nunit 및 Typemock 사용 )를 시작했기 때문에 더 높은 코드 적용 범위에 도달하고 출시 기간이 단축되었습니다.

대부분의 좋은 아이디어와 마찬가지로 채택은 아이디어의 품질보다는 조직의 경로 의존성과 더 관련이 있습니다.

제품을 출하 한 대부분의 회사에서 상당한 수준의 QA 책임자와 함께 실질적인 QA 부서가 만들어졌습니다. 테스트는 QA 팀의 핵심입니다.

QA 팀은 일반적으로 QA 팀에 강력한 코더를 배치하지 않기 때문에 단위 테스트 코드를 작성하지 않을 것입니다.

프로그래밍 팀은 QA 팀과 충돌을 일으키기 때문에 테스트 코드 작성을 꺼립니다.

QA가 별도의 직무로 분리되지 않은 그룹에서 단위 테스트에 대한 더 많은 관심과 채택을 보았습니다.

단위 테스트를 작성하고 업데이트하는 데 비용이 많이 듭니다. 대부분의 회사 이전 소프트웨어에는 단위 테스트가 없으며 작성하는 데 너무 많은 비용이 듭니다. 그래서 그들은 그것을하지 않고 개발 프로세스에 시간을 추가하므로 새로운 기능에도 추가하지 않습니다.

대부분의 회사는 쓸모가 없습니다. 분명히 당신 (또는 내가) 일하는 사람이 아닙니다.