단위 테스트 또는 테스트 중심 개발이 가치가 있습니까?

우리 팀은 Scrum으로 이사하고 있으며 다른 팀은 단위 테스트 및 사용자 승인 테스트를 사용하여 테스트 중심 개발을 시작하고 있습니다. UAT는 마음에 들지만 테스트 중심 개발 또는 테스트 중심 개발을위한 단위 테스트에서는 판매되지 않습니다.

테스트 작성은 추가 작업 인 것처럼 보이며 사람들이 실제 코드를 작성할 때 버팀목을 제공하며 종종 효과적이지 않을 수 있습니다.

단위 테스트의 작동 방식과 작성 방법을 알고 있지만 누구나 실제로 좋은 아이디어이며 노력과 시간이 가치가 있다고 주장 할 수 있습니까?

또한 TDD를 Scrum에 특히 좋게 만드는 것이 있습니까?

짧은 대답 : 절대적으로 긍정적입니다.

긴 답변 : 단위 테스트는 내가 일하고있는 장소 (대형 은행, FX 거래)에서 시도하고 영향을 미치는 가장 중요한 관행 중 하나입니다. 그렇습니다. 그들은 여분의 일이지만, 계속해서 갚는 일입니다. 자동화 된 단위 테스트는 실제로 작성중인 코드를 실행하고 기대치를 확인하는 데 도움이 될뿐만 아니라 미래의 변경 사항에 대한 일종의 워치 독 역할을합니다. 누군가 코드를 원하지 않는 방식으로 변경하면 테스트가 중단됩니다. 단위 테스트의 상대적 가치는 코드베이스의 예상 변화 수준과 성장 수준과 상관 관계에서 감소하지만, 예상되는 변화가 적은 곳에서도 코드의 가치에 대한 초기 검증은 필요합니다. 단위 테스트 값은 결함 비용에 따라 달라집니다. 결함의 비용 (비용이 시간 / 돈 / 평판 / 미래 노력의 손실 인 경우)이 0이면 테스트의 상대 값도 0입니다. 그러나 이것은 상업 환경에서는 거의 해당되지 않습니다.

우리는 일반적으로 일의 일부로 일상적으로 단위 테스트를 작성하지 않는 사람들을 더 이상 고용하지 않습니다. 그것은 매일 우리처럼 기대하는 것입니다. 단위 테스트를 수행하는 것에 대한 순수한 비용 편익 분석을 보지 못했지만 (누군가 나에게 자유롭게 가리킬 수 있음) 상업 환경에서 큰 중요한 시스템에서 코드 작동을 증명할 수 있다는 경험에서 볼 수 있습니다. . 또한 내가 작성한 코드가 (특정 수준으로) 작동한다는 것을 알고 밤에 더 잘 수 있습니다. 변경되면 누군가가 깨진 빌드로 예기치 않은 부작용을 경고합니다.

테스트 중심 개발은 제 생각에는 테스트 방식이 아닙니다. 실제로는 출력이 작동 시스템이고 일련의 단위 테스트가있는 디자인 접근법 / 실습입니다. 개발과 완성이 매우 어려운 기술이기 때문에 저는이 관습에 대해 덜 종교적입니다. 개인적으로 시스템을 구축 할 때 시스템 작동 방식에 대한 명확한 아이디어가 없다면 TDD를 사용하여 어두운 곳에서 길을 찾을 수 있도록 도와 줄 것입니다. 그러나 기존 패턴 / 솔루션을 적용하는 경우 일반적으로 적용되지 않습니다.

단위 테스트를 작성하는 것이 타당하다는 수학적 증거가없는 경우, 장기간 시험해보고 직접 혜택을 경험하는 것이 좋습니다.

이전에 발견 된 오류는 나중에 발견 된 오류보다 수정 비용이 저렴합니다. TDD는 시스템의 정확성을 확인하는 데 도움이됩니다. 조금 더 선불 투자하지만 나중에 다시 가져 오십시오. 그래프는 약간 과장되었지만 아이디어를 잘 보여줍니다.

이미지 소스

단위 테스트 또는 테스트 중심 개발은 가치가 있습니까?

그렇습니다 . 밥 아저씨 (로버트 C 마틴)는 프레젠테이션에서 말했다.

개발자가 자신의 코드가 테스트 를 작성하고 소리를 지르거나 노래하거나 춤을 추는 것 보다 더 잘 수행하고 있음을 증명할 수 있습니다.

또한 테스트를 삭제하지 않기 때문에 테스트가 통과하는 한 기능이 작동하는지 확인하십시오 . 회귀 문제가 해결되었습니다.

그것에 쓰여진 많은 것들이 있습니다.

1. 해당 기능을 작동시키는 것은 귀하의 책임입니다. 테스트를 작성하십시오. 그냥 해.
2. 단위 테스트를 통합 테스트로 교체하는시기

스크럼, 단위 테스트 및 TDD는 관련이 있습니까?

곧, 당신이 마스터 일 Unit testing때에 가까워 질 것 TDD입니다. SCRUM 은 이것과 아무 관련이 없지만, 훌륭한 내용 이 잘 섞여 ​​있음을 알 수 있지만 소프트웨어 개발 기술은 시도하지 않은 경우 훌륭한 스택에 추가됩니다 .

TDD를 SCRUM에 특히 좋게 만드는 것이 있습니까?

위에서 말했듯이 그들은 좋은 조합을 만듭니다 ; 자동화 테스트를 추가하면 더 특별 합니다.

테스트 작성은 추가 작업 인 것처럼 보이며 사람들이 실제 코드를 작성할 때 버팀목을 제공하며 종종 효과적이지 않을 수 있습니다.

단위 테스트는 목발로 가치가 있습니다. 개발 노력을 지원하므로 응용 프로그램이 필요에 따라 작동하지 않을까 걱정하지 않고 구현을 변경할 수 있습니다. 단위 테스트는 구현이 요구 사항과 일치하는지 확인할 수있는 도구를 제공하기 때문에 목발 그 이상입니다.

단위 테스트, 승인 테스트, 통합 테스트 등 모든 테스트는 테스트를 사용하는 사람들만큼 효과적입니다. 작업에 느슨하게 접근하면 테스트가 거칠어지고 구현에 문제가 발생합니다. 왜 귀찮게? 자신과 고객에게 소프트웨어가 작동하고 소프트웨어 사용을 방해 할 수있는 문제가 없음을 증명해야하기 때문에 테스트를 귀찮게합니다. 예, 테스트는 확실히 추가 작업이지만 테스트를 진행하는 방법에 따라 릴리스 후 버그 수정에 얼마나 많은 노력을 기울여야하는지, 코드를 변경하고 유지 관리하는 데 얼마나 많은 노력이 필요한지 결정합니다.

단위 테스트의 작동 방식과 작성 방법을 알고 있지만 누구나 실제로 좋은 아이디어이며 노력과 시간이 가치가 있다고 주장 할 수 있습니까?

TDD, 그리고 실제로 코드를 작성하기 전에 테스트를 작성해야하는 모든 방법은 향후 기술 부채에 대한 계약금으로 초기에 노력한 방식을 취합니다. 프로젝트를 진행할 때 누락되거나 제대로 구현되지 않은 것은 유지 보수의 어려움이 증가하여 더 많은 기술적 부채가 발생하여 향후 비용 및 자원 조달 요구 사항에 직접적인 영향을 미칩니다. 사전 테스트를 수행하면 향후 기술 부채를 해결하기 위해 노력했을뿐만 아니라 코드를 실행하여 요구 사항을 간단히 확인할 수있는 방식으로 요구 사항을 인코딩 할 수 있습니다. 먼저 테스트는 코드로 문제를 해결하기 전에 문제 영역에 대한 이해를 검증 할 수있는 기회를 제공하며 구현 노력을 검증합니다.

실제로 코드의 비즈니스 가치를 극대화하려고 시도합니다. 테스트를 거치지 않고 유지하기 어려운 코드는 일반적으로 작성하기가 저렴하고 빠르며 출시 후 제품 수명 기간 동안 유지 관리하는 데 비용이 많이 듭니다. 단위 수준에서 철저히 테스트 된 코드는 일반적으로 작성하는 데 비용이 많이 들지만 출시 후 제품 수명 기간 동안 유지하는 데 비용이 상대적으로 적습니다.

또한 TDD가 SCRUM에 특히 좋은 점이 있습니까?

TDD는 특정 방법론에 특별히 적합하지 않습니다. 단순히 도구입니다. 특정 결과를 달성하기 위해 개발 프로세스에 통합 할 수있는 방법. 따라서 귀하의 질문에 대답하기 위해 TDD는 SCRUM이든 다른 접근법이든 상관없이 귀하의 방법을 보완합니다.

사람들은 그것이 선행 활동이기 때문에 추가 노력이라고 생각합니다. 당신이 지금 잃어버린 것은 나중에 다시 돌아옵니다.

단위 테스트에 대한 나의 이유는 다음과 같습니다.

당신에게 목표를 준다 : 당신은 소프트웨어가 무엇을해야하는지 모른다면 테스트를 작성할 수 없다. 이를 통해 나중에 사양이 아닌 사양 문제를 해결할 수 있습니다.

진보의 느낌을줍니다.

코드 변경으로 인해 다른 코드 영역의 출력이 변경되면 경고합니다. 리팩토링이 더 쉬워집니다.

추가 문서 계층을 제공합니다 (특히 테스트 내용을 올바르게 언급 한 경우).

모든 종류의 모범 사례를 장려합니다. 테스트는 빠르게 실행되어야하므로 분리되어 조롱을 지원하는 코드를 작성하는 것이 좋습니다. 이것은 모두 리팩토링을 돕습니다.

이 글타래의 다른 게시물에서도 다른 내용을 다룹니다. 그만한 가치가 있습니다.

단위 테스트 또는 테스트 중심 개발이 가치가 있습니까?

확실히 그렇습니다 (다른 답변을보십시오)

정말 좋은 생각이고 노력과 시간 가치가 있습니까?

• 예. 새로운 것을 시작하면 (새 모듈 또는 완전히 새로운 응용 프로그램 추가)
• 없음 테스트 주도 개발되지 않았고 그 (레거시)를 확장해야합니다 기존의 많은 코드가 이미있는 경우.

내 생각에 테스트 중심 개발은 실제 코드 전에 단위 테스트를 작성하는 경우 가장 효과적 입니다. 이런 식으로 테스트를 수행하는 코드는 쉽게 테스트 할 수있는 최소한의 외부 참조로 명확하게 분리됩니다.

만약 유닛 테스트없이 코드가 이미 존재한다면, 쉬운 테스트를 위해 코드가 작성되지 않았기 때문에 나중에 유닛 테스트를 작성하는 것은 많은 추가 작업이 필요합니다.

TDD를 수행하면 자동으로 코드를 쉽게 테스트 할 수 있습니다.

다른 쪽에서 접근하겠습니다. 단위 테스트없이 사소한 응용 프로그램을 개발하면 어떻게됩니까? 좋은 품질 보증 부서가 있다면 가장 먼저 발생하는 문제 중 하나는보고 된 많은 문제가 있다는 것입니다. 왜 당신이 한 일을 테스트하지 않았고 그것이 효과가 있다고 가정하고 요구 사항에 많은주의를 기울이지 않았고 응용 프로그램이 요구 사항을 충족시키지 못하기 때문입니다. 다시 작성하고 수정하기 위해 드로잉 보드로 돌아갑니다. 이제 QA로 넘어 가기 전에 수정 사항이 다른 것에 영향을 미치지 않았는지 확인할 방법이 없었으므로 수정 사항을 작성하고 완전히 새로운 문제를 발견했습니다. 죄송합니다 마감일이 지났습니다. 경영진이 화가났습니다.

QA 부서가 없으면 상황이 더 나빠질 수 있습니다. 사용자가 버그를 발견하고 상사를 불행하게 만들뿐만 아니라 프로덕션 환경을 무너 뜨릴 수도 있고, 수백 또는 수천 명의 사람들이 단위 테스트로 방지 할 수있는 버그를 수정하는 동안 정지합니다. 이것은 좋은 직업 선택이 아닙니다.

이제이 카우보이 접근 방식이 몇 년 동안 계속된다고 가정 해보십시오. 이제 모든 변화, 심지어 사소한 변화조차도 새로운 의심의 여지가없는 문제를 일으키는 것처럼 보입니다. 뿐만 아니라 응용 프로그램의 성능을 향상시키기 위해 수행하려는 많은 작업은 너무 위험하거나 너무 비싸거나 둘 다이므로 수행 할 수 없습니다. 따라서 패치에 패치를 적용하면 시스템이 점점 더 복잡하고 버그가 많고 사용하기 어려워집니다.

사용자는 시간이 갈수록 커지고 있기 때문에 예상 시간에 의문을 제기하기 시작하고 시스템이 그렇게 복잡한 혼란에 빠졌다고 설명하기가 어렵습니다. 변경해야 할 부분을 찾기가 어렵고 여전히 확인하기가 더 어렵습니다. 다른 것을 끊지 마십시오.

저는 10 년의 개발 기간이 지난 후 실제로는 수백 개의 맞춤형 클라이언트 응용 프로그램 중 어떤 것이 고장 날지 알 수 없었기 때문에 실제 문제를 해결하기 위해 실제로 할 수있는 일은 없었습니다. 초기 개발자는 "단위 테스트, 우리는 악취 단위 테스트가 필요하지 않습니다"종류의 개발자였습니다. 그들을 따르는 모든 사람들은 근시 덕분에 어려움을 겪었습니다.

단위 테스트가 없으면 소프트웨어는 버그가 많으며 처음 개발하고 유지하는 데 더 오래 걸립니다. 지구상에서 왜 단위 테스트를 원하지 않습니까? 테스트 작성에 소요되는 시간은 이전에 발견했던 문제를 수정하는 데 걸리는 시간 (버그가 더 일찍 발견되는 데 걸리는 시간이 짧음)과 테스트를 작성하여 피해야 할 문제보다 훨씬 적습니다. 먼저 코딩을 시작하기 전에 요구 사항을 더 잘 이해합니다.

작성하는 모든 코드는 어느 시점에서 테스트해야합니다. 한 번에 모든 것을 작성하고 컴파일 버튼을 누르고 손가락을 교차시키고 싶지 않습니다. 작은 블록을 작성하고 컴파일하고 코드에서 신중하게 조작 된 입력을 보내서 생각하는대로 작동하는지 확인합니다. 그런 다음 일반적으로 임시 테스트 장치를 삭제하고 다음 구성 요소로 넘어갑니다.

단위 테스트를 통해이 프로세스를 단순화하고 테스트를 계속할 수있는 변명을합니다. 이렇게하면 과거에 테스트 한 내용을 손상시키는 변경 사항을 적용하면 해당 회귀를 코드의 다른 부분에 영향을 미치지 않고 명시 적으로 잡을 수 있습니다. 그것에 진정한 가치가 있습니다.

TDD에 대한 적록 리 팩터 접근법에 관해서는 약간 지루합니다. 그러나 각자 자신에게.

대부분의 경우 개발자는 테스트 작성 아이디어에 탄력적입니다. 그들이 시험에 가치가 없다고 주장하는 것은 그리 많지 않고 단지 특정한 문제를 해결하는 방법을 알아 내기위한 수단 일 뿐이다. 일반적으로이 문제는 상황에 따라 변경됩니다. 일단 완료되면 테스트는 목적이 없으며 삭제 될 수도 있습니다. 다음은 내 동료들이 테스트 작성시기를 결정하는 방법에 대해 과거에 제시 한 상황에 대한 샘플이며, 그에 따라 유일하게 가능한 답변은 다음과 같습니다.

• 당면 문제는 스택이나 계산기와 같은 TDD에 대한 교과서 예제 여야합니다.
• 사소한 코드는 테스트하지 않아야합니다 (이전 인수를 무효화 함).
• 중요하거나 어려운 코드는 철저히 테스트해야합니다 (이전 인수에 의해 암시 됨)
• 스위핑 리팩토링을 허용하기 위해 테스트에 구현과 결합해서는 안됩니다 (이전 인수 무효화)
• 특정 페이로드로 타사 서비스 호출과 같은 부작용에 대한 테스트는 필요하지 않으므로 블랙 박스 테스트는 필요하지 않습니다.

실제로 내가 찾은 한 가지 유형의 테스트가 일반적으로 허용되며 궁극적으로 쓸모가 없다고 생각합니다. 즉, 셀레늄, 웹 드라이버, watir 또는 arquillian을 사용한 GUI 기반 테스트. 이것이 TDD 프로젝트에서 5 분의 빌드주기가 아닌 7 시간의 빌드주기를 얻는 방법입니다.

이 같은 개발자들은 대개 코드가 얼마나 나쁘고 이전 개발자가 무능해야했는지 다른 모든 사람들에게 불평합니다. 또한 화이트 보드, MS 오피스 또는 Wiki를 사용하여 적절한 디자인을 만들고이 디자인이 최신 상태를 유지하도록주의를 기울여야합니다.

마지막은 그러한 개발자들이 사기라는 것을 깨닫게 해주었습니다. 단위 테스트가 아닌 설계 문서는 구식이 될 것이며 유지 보수 비용이 많이 들기 때문에 최신 상태로 유지되지 않을 것입니다. 사실 저는 코드 작성의 전후에 유용하고 읽기 쉬운 MS 오피스 형식으로 디자인 아이디어를 표현할 수있는 좋은 방법을 찾으려고 노력했습니다. 나는 모든 경우에 실패했으며 꽤 보이는 MS 오피스 문서를 제작하는 사람들이 있지만 실제로는 실제로 유용한 것을 찾지 못했습니다.

따라서 선택하실 수 있습니다. 10 년간의 개발 경험을 바탕으로 이러한 문서를 작성하는 유일한 방법으로 입증 된 TDD를 연습하여 설계 및 문서화를 수행 할 수 있습니다. 아니면 정치에 갈 수 있습니다.