프로그래머의 단위 테스트가 필요합니까? [닫은]

많은 IT 프로젝트를 구매하는 곳에서 일합니다. 우리는 현재 미래 프로젝트의 요청에 대한 시스템 요구 사항에 대한 표준을 만들고 있습니다. 이 과정에서 우리는 공급 업체로부터 자동 단위 테스트를 요구할 수 있는지 여부를 논의하고 있습니다.

적절한 자동화 된 단위 테스트가 코드의 품질과 안정성을 문서화하는 유일한 방법이라고 확신합니다. 다른 모든 사람들은 단위 테스트가 공급 업체 만 고려하는 선택적 방법이라고 생각하는 것 같습니다. 따라서 자동화 된 단위 테스트, 연속 테스트, 적용 범위 보고서, 단위 테스트 검사 또는 그 밖의 어떤 종류의 요구도하지 않습니다. 이 정책은 매우 실망 스럽습니다.

나는 여기서 완전히 벗어 났습니까?

의견에 대한 논쟁을 제공해주십시오.

적절한 자동 단위 테스트가 코드의 품질과 안정성을 문서화하는 유일한 방법이라고 확신합니다.

문제는 사람들에게 강제로 적절한 자동 단위 테스트를 수행 하지 않는다는 것입니다 . 이 방법은 까다로운 테스트를 받고 프로젝트 비용을 높이는 좋은 방법입니다.

개인적으로 저는 품질과 관련된 수요 나 SLA를 기대합니다. 달성 방법에 관계없이 10 년 전 단위 테스트는 거의 없었습니다. 품질을 보장 ​​할 수있는 더 나은 방법이 있지만 10 년 후에 공급 업체를 수갑으로 만들고 싶지는 않지만 구식 정책에 따라 기존 방식을 사용해야합니다.

개인적으로 나는 당신의 경우에 당신은 대신에 합격 시험에 대해 생각해야한다고 생각합니다.

• 블랙 박스가 제공되며 특정 방식으로 작동 할 것으로 예상합니다.
• 지불 할 때까지 지불하지 않습니다.
• 확인해야 할 동작을 수행하는 단위 테스트를 작성하고 실패하면이를 수정해야합니다.

또한 이것은 신뢰의 문제입니다. 공급 업체를 신뢰할 수없는 경우 소스 코드를 얻어 검사 한 후 직접 컴파일해야합니다. 그보다 적은 것은 최소한 당신이 그들 중 일부를 신뢰한다는 것을 의미합니다 .

적절한 자동 단위 테스트가 코드의 품질과 안정성을 문서화하는 유일한 방법이라고 확신합니다.

이 생각이 얼마나 흔한 지 놀랍습니다. 자동화되었습니다. 단위 테스트 (단독) 자동화 된 소프트웨어 테스트에는 단위 테스트보다 더 많은 방법이 있습니다. 통합, 시스템, 기능, QA는 어떻습니까? 어떤 이유로 사람들은 "좋아요, 우리는 적절한 단위 테스트를 가지고 있습니다. 테스트를 마치고 금요일 저녁이라고 부릅니다!" . 단위 테스트는 시작에 불과합니다.

어쨌든 주제로 돌아갑니다. 나는 다른 사람에게 어떤 것도 강요하면 원하는 것과 반대의 결과를 낳을 것이라고 다른 사람들과 동의합니다. 당신은 팀이 어떻게 작동하는지 알지 못합니다. 아마도 백만 달러 가치의 테스트 부서를 얻었고 결코 단일 단위 테스트를 작성하지 않았습니다.

첫 번째 직장에서 나는 우리가 0 단위 테스트를했던 곳에서 일했었습니다 (우리는 많은 주니어가 다소 심각한 물건을 던졌습니다). 믿거 나 말거나, 효과가있었습니다. 물론, 아무도 털어 없었다 왜 이 버그가 수정되었다, 또는 어떤 이 수정은 부러졌지만, 그것은했다. 절대적으로 임의의 버그가 튀어 나오는 시간이 있었지만야구 방망이와 아파트가 타 버릴 위험이 있습니다약간의 추가 시간은 놀라운 일을 할 수 있습니다. 공급 업체가 비슷한 기술을 사용하고 있습니까?

귀하의 경영진이 계약에서 적절한 단위 테스트 비용을 기꺼이 지불 할 것임을 의심합니다. 적절한 단위 테스트는 테스트하는 코드만큼 비용이 들지만 최종 사용자에게 거의 인식되지 않은 가치를 제공하므로 똑같이 가치있는 것으로 보이지는 않습니다. 품질 개발 회사는 다른 부품보다 적은 비용으로 단위 테스트에 대한 개발 노력을 기꺼이 할 것입니다. 작업에 해를 끼치 지 않기 때문에 동일한 시간을 필요로하지 않는 2 개의 계약을 더 많이 찾을 수 있습니다 단위 테스트 요구 사항.

까다로운 단위 테스트는 수신 한 견적을 불합리한 수준으로 증가시킬 수 있으며, 더 낮은 가격을 얻기 위해 처음으로 양보 될 것입니다.

단위 테스트를하지 않는 비용은 코드를 얼마나 확장 / 지원할 것인지에 따라 다릅니다. 품질 아이디어를 얻기 위해 코드의 일부를 검사하는 것도 중요합니다.

프로젝트를 구매하여 타사 라이브러리처럼 사용할 수 있고 수정하지 않을 경우 실제로 작동하는 한 품질이 낮은 코드의 위험은 줄어 듭니다.

결정을 내리는 사람이 기술적 가치를 알고 있는지 확인해야하지만 궁극적으로 비즈니스 결정입니다. 경영진에게 설명해야한다면 중고차를 사는 것과 같다고 설명하십시오. 궁극적으로 가치가 있는지 결정하는 것은 구매자의 몫이지만 기계공에게 가져가는 것이 좋습니다.

비용을 지불하면 모든 단위 테스트의 사본 / 보고서를 포함하여 원하는 것을 요구할 수 있습니다.

테스트를 작성하거나 최소한 테스트 사양을 직접 작성할 수도 있습니다.

코드 품질을 매우 잘 측정한다는 견해에 동의합니다. 공급 업체가이 요구를 거부하면 경보 벨이 울릴 것입니다. 왜 품질 기준이 낮고 지름길이 필요한가요?

프로젝트에 자동화 된 단위 테스트, 지속적인 테스트, 적용 범위 보고서 및 단위 테스트 검사가 필요하다는 것은 전적으로 옳습니다.

그러나 까다로운 것은 다른 사람들이 자세하게 원하는 결과를 얻지 못할 것입니다.

당신의 도전은 사람들을 설명하고 설득하는 것입니다-훨씬 더 어려운 기술!

처음에는 경영진으로 시작하여 테스트의 장단점과 그 결과를 설명합니다. '나는 적절한 단위 테스트를 작성하십시오'(자본 작성)와 같은 진술 뒤에 감정을 전달하지 않도록주의하십시오. 당신은 사람들이 자신이 올바른 해결책을 선택할 수 있도록 설득하고 설득해야 할 단어를 (모든 CAPS가 암시하는 것처럼) '소리로 외치지'않기를 원하지 않습니다.

궁극적으로 이러한 방법론을 소개 할 수없고 자신이있는 곳에서 그들을 포용 할 수 있다면, 그리고 당신이 말한 것처럼 그들에 대해 열정을 가지고 있다면 (좋아요!) 나는 이런 것들을 가치있게 여기는 많은 사람들이 있기 때문에 다른 회사에 갈 것입니다 기내에서 당신을 환영합니다. 인터뷰에서 상대방과의 관계를 미리 파악하여 열정이 어디에 있는지, 잘 맞는지 확인하십시오.

@Joachim Sauer와 @Telastyn이 의견에서 지적한 것처럼 누군가에게 자동 테스트를 강요하면 원하는 결과를 얻지 못합니다. 많은 사람들에게 자동화 된 단위 테스트는 그들의 생각에 큰 변화입니다. 많은 사람들이 작동하지만 테스트 할 수없는 코드를 작성하기 때문입니다. 모든 논리, 데이터베이스 쿼리, 비즈니스 규칙, 개체 등이 코드 뒤에있는 ASP.NET 웹 페이지를 작성할 수 있습니다. 페이지가 작동합니까? 예. 자동화 된 단위 테스트를 사용하여 테스트 할 수 있습니까? 절대적으로하지. 공급 업체에 자동 단위 테스트가없는 경우 단위 테스트를 올바르게 작성하는 방법을 배우고이를 학습 한 결과 코드를 다시 작성하거나 리팩토링하여보다 쉽게 ​​테스트 할 수 있도록 노력해야합니다. 그들은 당신에게 그 비용을 전달할 가능성이 있습니다.

문제는 공급자가 제품을 제공한다는 것입니다. .dll 또는 Windows 응용 프로그램이든, 99 %의 시간 동안 작동 할 것으로 기대합니다. 물론 여기저기서 버그가 있지만 대부분 제대로 작동합니다. 특히 공급 업체가 귀하의 비즈니스를 유지하고자하는 경우 이는 합리적인 기대입니다. 블랙 박스라면 어떻게 작동하는지는 중요하지 않습니다. 인간의 테스터 나 원숭이가 무작위로 열쇠를 때리는 방을 사용할 수 있습니다. 그것이 작동하는 한. 그러나 사용 방법에 대한 다른 종류의 문서를 제공해야합니다.

그러나 소스 코드를 제공하여 수정할 수 있으면 단위 테스트가 필요합니다. 단위 테스트를 제공하지 않는 회사와는 협력하지 않을 것입니다. 수정 한 내용이 전체를 호스 핑하지 않는다는 것을 어떻게 알 수 있습니까?

단위 테스트는 공급 업체가 개발주기 동안 위험을 처리하는 방법을 나타냅니다. 단위 테스트를 사용하는 사람들은 위험을 줄이고 가치를 테스트하는 것은 관리 된 위험의 양을 나타냅니다.

그러나 단위 테스트는 프로젝트가 어떤 수준의 위험을 감수하려고하는지 정의하지 않습니다. 또한 나쁜 프로그래밍 관행으로 인한 위험을 줄이는 데 아무런 역할을하지 않습니다.

따라서 확실한 테스트 관행을 가지고 있지만 위험성이 높은 코드를 계속 작성하는 공급 업체와 테스트를 수행하지 않지만 위험 코드가 적은 공급 업체가있을 수 있습니다. 두 공급 업체가 동일한 제품을 제공하는 경우 저 위험 공급 업체와 함께하는 것이 가장 좋습니다.

이는 공급 업체와 관련된 사람들의 성격과 기술에 대한 인터뷰, 멘토링 및 학습을 통해서만 측정 할 수 있습니다.

나는 커스텀 소프트웨어 구매에 대한이 기사가 매우 유용하다는 것을 알았다 : http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

그들이 권장하는 첫 번째 질문은 공급 업체가 테스트를 작성하는지 여부입니다.

요구되는 단위 테스트를 요구하는 다른 사람들과의 합의는 테스트를위한 테스트로 이어질 것입니다. 당신이 원하는 것과 매우 반대되는 것입니다.

공급 업체를 심사하는 과정에서; 테스트는 프로세스의 일부일 뿐이므로 개발 프로세스 가 무엇인지 물어보십시오 .

자동화 된 빌드 프로세스가 있습니까? 그들은 어떤 관리 패러다임을 따르고 있습니까? 그들은이 있습니까 제대로 훈련 테스터 와 독립적 인 품질 보증 팀 ? 문서 표준은 어떻습니까?

이를 통해 공정의 전반적인 품질을 판단하고 생산 된 제품의 품질을 판단 할 수 있습니다.

이 요구 사항을 포함시키는 것은 시행이 불가능하기 때문에 실질적인 이점이 거의없는 것 같습니다.

실제 테스트를위한 코드 또는 실제 테스트가 실행 및 통과 한 보고서를 요구할 수 있습니다. 독점 프로젝트 인 경우 공급 업체는 코드의 세부 정보를 강력하게 암시 할 수 있기 때문에 공급하지 않을 것입니다. 낮은 수준의 구현 세부 정보를 제공하고 해당 작업을 수행하는 방법을 알려주는 데 어려움을 겪을 수 있습니다. 직업. 어느 시점에는 신뢰가 있어야합니다.

그렇지 않은 경우 유틸리티를 컴파일하고 실행하거나 이와 비슷한 반값으로 통과하는 단일 테스트를 작성하여 요구 사항을 충족하기 위해 "단위 테스트 실행"옆의 상자를 선택하면 날아갈 수 있습니다. 노력.

따라서 자동화 된 단위 테스트는 훌륭한 관행이지만 외부 벤더로부터이를 주장하는 것이 실용적이지 않다고 생각합니다.

많은 사람들이 지적했듯이, 벤더가 계약을 이행하기 위해 단위 테스트 (또는 더 나은 자동화 된 단위 및 통합 테스트의 조합)를 작성하도록 강요하면 고품질 결과를 얻지 못할 수 있습니다. 반면에, 자동화 된 테스트는 현재 코드 품질을 보장하기 위해 현재 사용중인 최상의 방법이라는 데 동의합니다.

단위 테스트로 작성된 코드는 처음 작성되고 나중에 단위 테스트가 추가 된 코드보다 유지 관리가 훨씬 쉽다고 생각합니다 . 그것은 모듈 성과 최소한의 의존성을 강요합니다. 코드의 정확성을 검증하기 위해 통합 테스트가 필요하지만 코드의 품질에 영향을 미치지는 않습니다. 본질적으로 자동화 통합 테스트는 사실 이후에 추가 될 수 있지만 단위 코드는 원래 코드로 작성 될 때 가장 큰 영향을 미칩니다.

귀하의 상황에 대한 조언은 단위 테스트로 코드를 작성하는 것을 선호하는 벤더를 찾고 단위 테스트로 코드를 작성하지 않는 벤더보다 선택하는 것입니다. 경영진이 비용을 지불 할 경우 계약서에 자동 테스트를 실시하지만 벤더가 단위 테스트로 코드를 작성하는 데 사용되는 경우에만 가능합니다.

우선 순위를 바로 잡자 ...

고객으로서의 역할에서 주요 관심사 는 단위 테스트가 아닙니다.

소프트웨어를 생산하는 공급 업체를 사용하는 경우 한 가지 방법론을 사용하는지 걱정할 필요가 없습니다. 당신의 목표는 당신의 목표를 달성하는 데 도움이되는 일종의 해결책을 얻는 것입니다. 당신이 신경 써야 할 유일한 것은 그 해결책이 수용 가능하다는 것입니다. 이것이 바로 고객이 원하는 것을 얻을 수 있도록하는 책임에 따라 승인 테스트 를받는 이유입니다. 고객 수용의 중요한 순간에 돈이 회사의 주머니에서 공급자의 주머니로 거래됩니다.

단위 테스트를 제공 가능한 요구 사항으로 요구할 수 있지만 몇 가지 상속 문제가 있지만 가장 심각한 것은 메트릭을 결정할 사전 확실한 방법이 없다는 것입니다.

• 허용되는 단위 테스트 양은 얼마입니까?

10 개의 테스트가 있어야합니까? 100 번의 테스트는 어떻습니까? 1000 번의 테스트는 어떻습니까? 실제로 처음에 필요한 테스트 수를 결정하는 것은 매우 어렵습니다. 실제 숫자는 실제로 ... 정지 문제와 같이 결정할 수 없지만 ... 그 문제를 해결하고 있지 않습니다.

단위 테스트가있는 소프트웨어 만 있으면 개발을 계속할 수 있습니다. 단위 테스트는 아직 무엇을 깨뜨 렸는지 알려주지 않지만 코드에 회귀 버그가있는 경우 알려주는 데 적합합니다.

• 허용되는 코드 적용 수준은 무엇입니까?

"물론 100 %!" 당신은 생각할 것입니다. 불행히도 그 지표는 오도의 소지가 있습니다. 100 % 코드 적용 범위를 가지고 있어도 예상대로 작동 하는지 확실 합니까? 100 % 적용 범위를 가질 수 있지만 완료되지는 않습니다.

실제로해야 할 일은 탐색 적 테스트입니다. 즉, 물건을 깰 수있는 사람을 찾아서 테스트를하도록합니다. 개발자가 생각하지 못한 버그를 찾기 위해.

또한 필요한 성능 해킹이 있고 테스트하기 어려운 디자인 패턴을 사용하는 경우 (원하는 검색 엔진에서 "singleton"및 "tdd"를 검색하면 몇 가지 예를 찾을 수 있음) 순수한 단위 테스트를 통해 100 % 달성 할 수없는 경우가 있습니다.

제공된 소프트웨어가 작동하기 를 원하며 사양 문서가 유일하게 보증합니다.

더 높은 수준의 테스트 가 필요합니다

사양 문서는 어떻게 든 검증되어야합니다. 각 목표는 명확한 목표와 수용 기준을 가진 공급 업체와 함께 진행되어야합니다. 제대로 작동하는 QA 조직 (예산이 한정되어 있고 범위가 제한된 경우 훌륭한 테스터)은 이러한 승인 기준을 확인하기위한 테스트 사례를 제공합니다. 또한 이러한 승인 기준을 검증 할 사람이 필요합니다.

목표를 확인하는 방법에는 여러 가지가 있으며, 누군가 제정신의 품질, 성능 및 효율성 목표를 설정할 수 없다고 말하면 탐색, 성능 및 유용성 테스트에 대한 크고 무거운 책으로 머리를 맞출 것입니다. 목표를 달성하기가 쉽지만 지식과 의사 소통은 현실적인 목표를 세우는 데 도움이됩니다.

저는 변호사는 아니지만 대부분의 프로젝트 계약 (기본적으로 프로젝트 의 모든 사양 의 어머니 임)을 읽습니다. 일반적으로 허용되는 버그 수를 규정하는 결함 비율 기준이 있습니다. 버그는 보통 심각도를 통해 결정되며, QA에서 발견 한 중단 방지 버그는 내성이 낮고 사소한 결함은 내성이 높습니다. 실제 프로젝트에서는 소프트웨어에 결함이 없어야한다는 것을 요구하기가 어렵습니다. 마감일은 보통 그 연습을 중단합니다. 이러한 상황에서 스코프 협상을 시작해야합니다.

내가 본 대부분의 제공된 소프트웨어는 일반적으로 단위 테스트와 함께 제공되지 않습니다. 공급 업체가이를 제공하기에 충분히 전문적이어야한다고 주장 할 수 있지만, 단위 테스트를 제공하려는 주된 이유는 회귀 버그가 발생하지 않고 리팩토링을 활성화해야하기 때문입니다. 공급 업체와 고객 모두 마감일이 촉박 한 실제 프로젝트에서 범위를 낮추고 단위 테스트는 일반적으로 창 밖으로 나가 필요한 결과물 목록에서 제거합니다.

하이 프로파일 오픈 소스 소프트웨어가 단위 테스트와 함께 제공되는 것은 슬픈 일이지만 전문 소프트웨어 개발자는 그렇지 않습니다.

고객으로서 언제 단위 테스트를해야합니까?

나는 것을 주장 단지 당신이 할 때 진정으로 걱정하는 단위 테스트가 전달 가능한 소프트웨어가 굵은이해야 할 당신이 할 수있는 테스트하는 독립 실행 형 프로그램으로 실행되지 않는 자급 자족 구성 요소는 단위 테스트가되는 경우이다 . 클래스 라이브러리는 단위 테스트와 함께 제공 될 수있는 일종의 제품입니다.

공급 업체가 단위 테스트를 작성하지 않는다는 것을 어떻게 알 수 있습니까?

어쩌면 경영진과 벤더가 회의를 가졌고 벤더는 코드 비용은 X 달러이고 단위 테스트 비용은 Y 달러라고 말했다. 페니 꼬집어 관리는 우리가 코드를 원한다고 말했다.

공급 업체는 어쨌든 (품질 때문에) 단위 테스트를 작성하고 경쟁 우위로 인해 공유하지 않기로 결정했습니다.

이제 소프트웨어를 약간 조정해야합니다. 코드를 소유하고 있기 때문에 코드를 직접 작성하거나 경쟁 업체로 고용 할 수 있습니다 (원래 공급 업체에 반드시 해당되는 것은 아님). 그러나 단위 테스트를 구매하지 않았으므로 원래 공급 업체는 경쟁 업체에 비해 저렴한 가격으로 비슷한 품질의 작업을 수행 할 수 있습니다.

단위 테스트를 사용하지 않는다는 사실에도 불구하고 매우 성공적인 프로젝트가 많이 있습니다. 일반적인 프로젝트에서 볼 수있는 것 이상의 복잡성을 가진 거대한 프로젝트 인 Linux 커널을 살펴보면 여전히 작동합니다. 따라서 결과가 좋은 소프트웨어라면 어떻게 달성했는지는 신경 쓰지 않아야합니다.

아니요, 완전하고 자동화 된 테스트 장치를 요구할 필요는 없습니다. 적절한 테스트 전략 문서를 제공하는 것이 더 중요합니다. 우리는 이런 식으로 잘하고 있습니다.