The Economics of TDD (TDD의 경제성)

[원본 문서]

https://semaphoreci.com/blog/economics-of-tdd

The Economics of TDD - Semaphore

 

[번역]

관리 관점에서 테스트 주도 개발(TDD) 도입을 설득하기 어려울 수 있습니다. 이는 상대적으로 큰 초기 투자를 수반하고, 명백한(정량적, 사업적으로 보여줄 수 있는) 비즈니스 이점이 없으며, (가장 중요한) 고객(회사)은 테스트가 아닌 기능에 대해 개발 비용에만 주로 관심이 있습니다.

그렇지만,  프로젝트의 다음 이정표에 도달하기 위해 테스팅(TDD)을 줄이려는 유혹은 잘못입니다. 왜냐하면 TDD가 프로젝트 생애주기(S/W의 개발부터 폐기될 때까지)동안 개발을 가속화하고 비용을 줄이는 데 도움이 될 수 있기 때문입니다.

TDD 란 무엇입니까?

TDD는 테스트를 설계의 기폭제로 사용하는 소프트웨어 개발 원칙의 집합입니다. TDD 주기는 세 단계로 구성됩니다.
(기폭제의 의미 : TDD는 기능 설계/구현이 보다 빠르게 진행되도록 하는 역할을 한다는 의미로 사용됨)

1. 테스트 (코드의) 작성 : 테스트는 코드의 동작, 입력 및 예상 출력을 정의합니다.
2. 구현(기능 로직 개발) : 테스트를 통과하는 최소한의 코드를 작성합니다.
3. 리팩터링(로직 정리/개선) : 구현을 개선하고 더 일반적이고 빠르며 읽기 쉽게 만듭니다. 이 테스트는 구현이 이 단계 동안 유효한지 확인합니다.

TDD는 테스트의 동의어가 아닙니다. 단순히 프로젝트에 몇 가지 테스트를 추가하고 TDD를 하고 있다고 말할 수 없습니다. 예를 들어, 구식 폭포수 개발 방법 은 프로세스가 끝날 때에도 테스트를 사용하며 TDD와 거의 정반대입니다.

(과거(10여년 전)에 유행하던 자동화 테스트는 구현 이후의 테스트를 지동화하는 것으로 TDD와 크게 다른 개념이며, 자동화테스트는 테스트 속도만 개선할 뿐 개발 속도는 개선하지 못함. 자동화 테스트는 유지에 비용이 많이 들어 현재는 대부분 기업에서 사용하지 않음)

문제는 테스트 단계가 너무 늦게 온다는 것입니다. 테스트가 실행될 즈음에는 그라운드(??) 피드백 없이 너무 많은 설계 결정이 내려졌습니다. 이 단계에서 구현된 테스트에 의해 밝혀진 심각한 문제는 종종 프로젝트를 드로잉 보드로 되돌려 보냅니다.

TDD의 정의적인 특징은 테스트를 사용하여 설계를 추진하는 것입니다. 즉, 코드가 작성되기 전에 디자인 프로세스의 맨 처음에 테스트가 나타납니다.

TDD는 짧은 테스트 생성 <-> 빠른 개발 반복을 촉진하는 피드백 루프를 구현합니다. 개발 중에 다양한 디자인과 여러 구현을 시도할 수 있습니다. 이는 개발자가 적시에 최적의 솔루션을 찾는 데 도움이 되며, 코드에 대한 확신을 주고 프로젝트를 순조롭게 진행합니다.

IEEE에서 실시한 설문 조사 에 따르면 TDD에는 다음과 같은 몇 가지 이점이 있습니다.

• 출시 시간 단축(30%) : TDD 프로젝트는 평균 30% 더 빨리 완료되었습니다.
• 결함 감소(40~80%) : TDD는 오류가 적은 코드를 생성했습니다. 버그 감소는 40%에서 80% 사이인 것으로 나타났습니다.
• 향상된 품질(최대 80%) : 일부 프로젝트는 가독성, 이해도 및 인지된 코드 품질에서 80% 향상을 받았습니다.

자동화된 테스트 스위트(Suite, 세트)를 작성하는 것은 투자입니다. 시간, 노력, 돈, 그리고 상당한 수준의 기술과 경험이 필요합니다. 더 나은 테스트를 작성하는 데 도움 이 되는 6가지 원칙 이 있습니다 .

1. 테스트는  품질을 향상시켜야 합니다 . 품질이 나쁜 코드가 체크인되면 테스트가 실패해야 합니다.
2. 테스트는  실패 의 위험을 줄여야 합니다  . 테스트는 테스트 코드 자체에 오류가 발생하지 않도록 최대한 단순해야 합니다.
3. 테스트  는 코드를 이해하는 데 도움이 됩니다 . 코드가 수행해야 하는 작업을 이해하기 위해 항상 테스트 사례를 참조할 수 있어야 합니다.
4. 테스트는  작성하기 쉬워야 합니다 . 사용하기 쉬운 테스트 프레임워크를 선택하고 시간을 들여 잘 학습해야 합니다.
5. 테스트 스위트는  실행하기 쉬워야 합니다 . 이상적으로 테스트는 개입 없이 자동으로 실행되어야 합니다.
6. 테스트 스위트는  최소한의 유지 관리 가 필요해야 합니다 . 테스트는 구현 세부 사항에 연결되어서는 안 됩니다. 이를 통해 테스트를 중단하지 않고 리팩토링할 수 있습니다.

TDD가 비용을 줄이는 방법

좀 더 구체적인 용어로 말하자면 노력(Effort)은 새로운 기능을 구현하거나 버그를 수정하거나 애플리케이션의 일부를 변경하는 데 필요한 작업량 으로 정의합니다.

노력은 일정하지 않습니다. 코드베이스가 커짐에 따라 변경됩니다. 폭포수 방식에서는 노력이 낮게 시작하여 꾸준히 증가합니다. 문제는 앞에서 보았듯이 피드백이 너무 늦게 와서 도움이 되지 않는다는 것입니다. 따라서 개발자는 추측과 직관에 의존해야 합니다.

TDD는 상황을 전환합니다. 처음에는 기능을 구현하는 대신 테스트를 작성하기 때문에 노력이 많이 듭니다. 또한 TDD로 전환하는 데 시간이 걸린다는 사실을 고려해야 합니다.

그러나 축소하면 TDD가 개발 비용을 증가시키지 않습니다. 사실, 특정 임계값 이후에는 TDD가 폭포수(TDD 이전의 개발 방식) 보다 훨씬 더 효율적이 됩니다.

시간이 돈인 세상에서 TDD의 초기 비용은 앞으로의 노력으로 상쇄됩니다. 프로젝트가 진행됨에 따라 다음과 같은 이유로 코드 변경이 더 쉬워집니다.

• 테스트를 통해 많은 디버깅 노력을 절약할 수 있습니다.
• 문제가 발생하면 즉각적인 피드백이 제공됩니다.
• 명확한 방향과 견고한 디자인이 있으면 코드에 더 집중할 수 있습니다.
• 코드는 더 깨끗하고 더 분리되어 변경하기 쉬운 경향이 있습니다.

TDD의 함정

TDD는 개발 워크플로에 그냥 연결할 수 있는 것이 아닙니다. 종종 TDD는 관리 및 엔지니어링 팀 모두에서 문화적 변화를 요구합니다.

테스트 작성은 코드 작성과 다른 기술이며 마스터하려면 경험이 필요합니다. 반만 적용하는 방식(어설픈 적용)으로 TDD를 시행하면 초기 투자에 대한 약속된 보상을 얻지 못할 것입니다. 사실, 잘못 작성된 테스트 스위트는 개발을 차단할 것 입니다.

경영진은 명확한 기대치와 일관된 로드맵을 설정하여 TDD 채택을 시도하기 전에 개발자가 참여하고 적절한 교육을 받도록 해야 합니다. TDD를 이해하고 적절하게 적용하지 못하면 좋지 않은 결과를 초래합니다. 결과적으로 개발자는 시간을 낭비하고 조직 전체에 실망감을 느끼게 됩니다. 다음은 TDD가 계획대로 진행되지 않을 때를 나타내는 몇 가지 징후입니다.

• 팀은 100% 적용 범위에 도달하기 위해 노력하고 있습니다.
• 테스트는 버그를 찾는 것뿐이라는 일반적인 사고방식.
• 테스트 스위트는 실행하기 쉽지 않습니다.
• 모든 테스트가 자동화된 것은 아닙니다.
• 테스트 스위트는 느리게 실행됩니다.
• CI/CD 파이프라인 을 실행 하는 데 10분 이상 걸립니다.
• 테스트가 구현과 너무 밀접하게 연결되어 있습니다.
• 테스트가 자체유도화기(쏘기만 하면 알아서 적기를 격추하는 유도 미사일) 솔루션이라는 만연화된 믿음
  (지속적으로 테스트를 빠르게하기 위해 정기적인 유지 관리가 필요한 투자와 반대의 개념)

결론

TDD를 시작하는 것은 어려울 수 있지만 게임 체인저입니다. 향상된 속도와 ROI는 폭포수와 같은 다른 개발 방법과 비교할 수 없습니다.

테스트 여정을 계속하려면 다음 게시물을 읽으십시오.

• 테스트 주도 개발(TDD): 품질 소프트웨어를 위한 오랜 시간 테스트를 거친 레시피
• 승인 테스트의 이점
• 비정상적 테스트를 찾고 제거하는 방법