저는 애자일 방법론을 연습하려는 수많은 팀에 근무했으며 종종 이러한 팀이 테스트 중심적입니다. 테스트는 애자일 방법론을 실천하는 데 필요한 부분입니까, 아니면 수년에 걸쳐 시행 된 XP 관행입니까?

애자일은 점진적 개선을 기반으로하기 때문에 애자일을 테스트하는 것이 절대적으로 필요합니다. 어려움은 때때로 현재 변경 사항이 이전 코드에 어떤 영향을 미치는지 파악하기 어려울 수 있습니다. 무언가를 깨뜨리지 않았다고 확신하는 가장 좋은 방법은 그것을 테스트하고 테스트하는 방법을 아는 것입니다. 그렇게하면 오래된 기능을 깨뜨린 코드를 작성할 때 한 일을 정확히 잊었을 때 즉시 버그를 찾을 수 있습니다.

이것이 기존의 하향식 설계 유형 프로그래밍과 다른 이유는 해당 환경에서 a) 완제품이 나올 때까지 테스트하기가 매우 어렵 기 때문입니다. b) 이론적으로는 모든 설계 기준을 동시에 고려하고 있기 때문입니다. 따라서 이전 설계 결정을 위반하는 설계 결정을 내릴 가능성이 줄어 듭니다.

자동화 테스트, 단위 테스트, 통합 테스트 등에 대해 이야기하고있을 것입니다. 수동 테스트 (테스터 등)보다 속도가 느리기 때문에 민첩하게 만드는 것이 중요합니다. 따라서 모든 작은 변경 사항을 테스트 할 수는 없습니다. 민첩성은 빠른 작은 반복에 관한 것이기 때문에 몇 시간 또는 며칠이 아닌 몇 초 또는 몇 분 안에 정확성을 검증하는 테스트를하는 것이 매우 유용합니다.

테스트가 없다면 코드가 어떻게 작동하는지 어떻게 알 수 있습니까?

편집 : 테스트가 코드가 작동 하는 것이 하나의 중요한 용어, 즉 작동 하지 않는다는 것을 증명할 수 없다는 주장 . 프로그램이 작동한다는 것은 무엇을 의미합니까? 이 용어를 모호하게 유지하면 프로그램이 작동한다는 것을 증명하거나 확신 할 수있는 방법이 없습니다. 이제까지.

반면, 작품 을 "사양에 따라 동작"으로 정의 할 수 있습니다 . 이제 테스트를 사용하여 코드가 작동 함을 보여줄 수있을뿐만 아니라 테스트 자체가 코드 동작의 실행 사양으로 사용될 수 있습니다. 다시 말해, 잘 작성된 테스트 스위트는 작동 하는 의미를 정의 합니다.

이 사고 방식은 또한 버그 의 의미를 재검토하도록합니다 . 코드가 모든 테스트를 통과하면 코드에 버그가 없습니다. 그럼에도 불구하고 시스템이 정상적으로 작동하지 않으면 해당 동작이 올바르게 지정되지 않은 것입니다. 나. 버그는 테스트에 의해 정의 된 사양에 있습니다.

소프트웨어 개발에 대한 이러한 접근 방식은 시스템의 기능 사양을 구현과 분리합니다. 이는 전 세계의 모든 소프트웨어 엔지니어링 책에 따르면 매우 좋습니다. 동시에이 접근 방식은 구현이 항상 기능 사양과 일치하도록합니다.

아니요, "필수"가 아닙니다

애자일 의 원칙 은 테스트에 대해 직접적으로 아무 말도하지 않습니다 .

그러나 그것은 매우 좋습니다

지속 가능한 프로세스, 지속적 / 증분 전달 및 소프트웨어 품질에 대한 Agile의 약속을 감안할 때 자동화 된 테스트는 현재 대부분의 프로젝트에서 사용할 수있는 최상의 솔루션입니다

예외는 (Jörg W Mittag에 의해 언급 된 바와 같이) 코드를 생성하는 메타 프로그래밍 시스템 등 교정 가능한 개발 도구를 포함합니다. 그러나 이런 종류의 시스템은 드물다.

Agile과 XP는 모두 Big Design Up Front 를 피하려고합니다 . BDUF에서는 요구 사항을 수집하고 공식 사양을 만든 다음 코딩을 수행 한 다음 테스트를 수행합니다. 이는 의료 장비, 우주 탐사선 등과 같이 잘 정의되고 미션 크리티컬 한 시스템에 적합합니다.

애자일 (Agile)은 잘 정의 되지 않은 문제 ( 예 : "클라이언트가 이번 주에 요청하는 변경 사항")에 대해서는 제대로 작동하지 않기 때문에이 흐름을 피합니다 . 우리는 여전히 공식적인 사양이 필요하기 때문에 무엇을해야하고 언제해야하는지 알지만 어떤 종류의 문서보다는 자동화 된 테스트 형식의 코드 를 사용 합니다 .

자동화 된 단위 테스트는 작성, 실행 및 모듈 / 분리가 빠릅니다. 따라서 요구 사항을 공식적으로 지정하고 확인할 수 있습니다.