GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
TDD란 무엇입니까?
비즈니스의 맥락에서 소프트웨어의 목적은 해당 비즈니스에 가치를 추가하는 것입니다. 이 때문에 모든 개발 노력의 주요 과제 중 하나는 비즈니스 요구 사항과 목표를 해당 시스템 요구 사항에 매핑하는 것입니다. 그 다음에는 이러한 요구 사항을 충족하기 위해 소프트웨어를 어떻게 작성합니까? 프로젝트와 코드베이스가 성장함에 따라 소프트웨어가 이러한 요구 사항을 계속 충족하도록 어떻게 보장합니까?테스트 주도 개발을 입력합니다.
TDD(Test-Driven Development)는 소프트웨어를 설명하고 실행하는 테스트를 작성하여 소프트웨어를 작성하는 조직적 방법론입니다. 핵심에서 TDD는 세 단계의 반복입니다 : 실패한 테스트를 작성하고, 통과하게하고, 리팩토링합니다.
개념은 개발되고 있는 소프트웨어 기능에 대한 기능을 설명하는 테스트로 시작한다는 것입니다. 테스트할 코드가 아직 작성되지 않았기 때문에 테스트를 처음으로 실행하면 오류가 발생합니다. 당연히 다음 단계는 원래 테스트를 통과하는 것을 목표로 기능을 구현하는 것입니다. 세 번째, 그리고 틀림없이 수명 주기의 가장 중요한 단계는 코드를 리팩토링하는 것입니다.
소프트웨어를 작성하는 것은 본질적인 특성뿐만 아니라 역동적인 특성 때문에 도전적입니다. 비즈니스 요구 사항은 끊임없이 변화할 수 있으며, 결과적으로 소프트웨어 요구 사항에 적응할 수 있어야 합니다. 오늘 작성된 코드는 오늘날의 요구에 맞을 것이지만, 내일 또는 내일 한 달 후에 무언가가 바뀔 것이며, 결과적으로 오늘의 코드는 더 이상 특정 문제를 해결하는 최선의 방법이 아닐 수도 있습니다. 소프트웨어를 비교하는 메커니즘을 도입하여 은(는) 소프트웨어 내용에 대한 기록 수행 해야 함 지금 우리는 두려움 없이 찢어 내고, 다시 쓰고, 그렇지 않으면 우리의 코드를 다시 배선하여 오늘날의 요구 사항을 가장 잘 충족시킬 수있는 강력한 도구를 가지고 있습니다. 왜냐하면 모든 테스트가 통과하는 한 시스템의 출력은 동일해야한다는 것을 확신 할 수 있기 때문입니다.
TDD를 사용해야 하는 이유는 무엇입니까?
헬싱키 대학이 실시한 2014 년 리뷰에 따르면 많은 경우 TDD는 결함, 품질, 복잡성 및 유지 관리 가능성 측면에서 긍정적 인 효과를 낳았지만 이러한 개선은 개발 노력을 증가시키는 대가로 나타날 수 있습니다. 추가 테스트를 작성하려면 추가 노력이 필요하다는 점을 감안할 때 이것은 놀라운 결론이 아닙니다.하지만 이러한 성격의 연구가 빠뜨리는 것은 TDD의 주요 이점입니다.
피드백 루프를 닫는 것은 변화를 만들고 무언가를 배우는 데 걸리는 시간을 줄이는 것을 의미합니다. 더 빨리 할 수 있을수록 더 민첩해질 수 있습니다. 개발 생산성을 정량화하려는 대부분의 지표는 시간 경과에 따른 작업 단위와 관련이 있으며, 실행 가능한 피드백을 받는 데 걸리는 시간을 줄임으로써 TDD를 통해 귀중한 리소스를 보다 효율적으로 사용할 수 있습니다. 시간은 돈이라고 알려져 있습니다. 그래서 경제적 이익은 자명합니다. 소프트웨어 개발 수명 주기의 맥락에서 누군가가 “좌파 교대”를 언급하는 것을 들어 본 적이 있다면 이것이 바로 그들이 말하는 것입니다.
응용 프로그램에 대한 테스트 스위트를 갖추면 이를 자동화할 수 있다는 또 다른 이점이 있습니다. 개발자는 이러한 테스트를 개발 수명 주기의 일부로 실행할 수 있을 뿐만 아니라 스모크 테스트 또는 CI/CD 파이프라인의 일부로 다른 시스템에서 실행할 수 있습니다. 코드를 시장에 전달하는 단계를 자동화함으로써 제품 전체를 보다 빠르게 전달할 수 있으며, 결과적으로 사용자로부터 피드백을 신속하게 전달할 수 있으며, 이를 해석하여 다음 번 반복 작업에 적용할 수 있습니다.
이 두 가지 요점의 시너지 효과는 분명합니다. 개발자가 비즈니스 요구에 맞게 코드베이스를 지속적으로 조정할 수 있고 비즈니스가 고객으로부터 신속하게 피드백을 요청할 수 있는 능력을 갖춘 코드베이스를 통해 팀이 적은 작업으로 더 많은 가치를 제공할 수 있는 시스템이 탄생했습니다.
TDD 최대한 활용
테스트 주도 개발은 소프트웨어 테스트에 대한 다양한 접근 방식 중 하나입니다. 어떤 방식으로 구현하든 중요한 부분은 조직에 가치를 제공한다는 것입니다. 다른 분야와 마찬가지로 조직의 요구에 전적으로 따라 자유롭게 사용하거나, 적절하다고 판단되는 대로 조정하거나, 전혀 사용하지 않아야 합니다. 즉, 만약 당신이 TDD 길을 걷기로 선택한다면, 선지자 Clapton이 예언한 것처럼, “그것은 당신이 그것을 사용하는 방식입니다.”
다른 도구와 마찬가지로 TDD의 효과와 가치는 구현에 따라 달라집니다. 소프트웨어 개발에서 프로젝트의 실패나 단점을 설명하기 위해 다양한 도구나 기술이 희생양으로 변하는 경우가 너무 많지만, 그의 도구를 비난하는 것은 가난한 장인입니다. 그럼 TDD를 최대한 활용하는 방법에 초점을 맞춰봅시다.
문화적 리팩터링
TDD의 가장 중요한 마지막 단계는 코드를 리팩토링하는 것입니다. 하지만 TDD가 작동하려면 리팩토링이 필요한 유일한 리팩토링이 아닐 수 있습니다. 테스트 주도 개발의 어떤 형태를 구현하기로 결정한 경우, 주변 문화도 이러한 스타일의 개발 철학을 지원하도록 적응하는 것이 중요합니다.
TDD의 경우 가장 일반적인 실패는 테스트를 작성하고 통과한 다음 리팩터링의 연속적인 주기가 실제로 완료되지 않고 리팩터링 단계를 건너뛰어 단락되는 경향이 있습니다. 종종 문제는 TDD 또는 다른 특정 기술이 아니라 소프트웨어가 개발된 바로 그 문화입니다.
문서와 달리 리팩토링은 마감일이나 예산이 수축될 때 가장 먼저 발생하는 것 중 하나인 것 같습니다. 결국 누군가는 이러한 모든 테스트를 작성해야 하기 때문입니다. 따라서 위기 시간 동안 테스트와 문서, 그리고 미션 크리티컬하지 않은 다른 모든 것이 제거됩니다. 변함없이 뒤따르는 것은 코드베이스의 전반적인 품질이 꾸준히 하락하고 그 대신에 기술적 부채가 축적된다는 것이다.
리팩터링은 단순히 작동하는 코드를 더 깔끔하고 유지 관리가 용이한 코드베이스로 변환하기 위해 노력하는 프로세스의 단계입니다. 개발자가 한 걸음 물러나 전체 시스템 내의 패턴을 인식하고 보다 다양한 용도로 적응하거나 새로운 안티 패턴을 인식하고 이를 완화하기 위한 조치를 취할 수 있는 보다 나은 결정을 내릴 수 있는 부분입니다. 전체 아키텍처를 개별 마이크로서비스로 분할하거나 다른 수많은 잠재적 개선 사항으로 분할해야 하는 시기를 인식하는 것의 차이일 수도 있습니다. 이 단계가 없으면 내성이나 점진적 개선의 기회를 놓칠 수 있으며 궁극적으로 코드베이스는 점진적으로 (또는 그렇지 않은) 진흙 덩어리로 변할 위험이 있습니다.
테스트 주도 개발의 이점을 얻으려면 문화가 전체 프로세스와 그 잠재력을 장기적으로 바라보고 편법 비트뿐만 아니라 완전한 “빨강, 녹색, 리팩터”주기를 적용하는 데 시간을 투자하는 것이 중요합니다.
빛나는 새로운 장난감
시스템 설계 전반에 관해서는, 실제로 코드를 작성하지 않고 시스템의 세부 사항을 계획하는 데 너무 많은 시간을 소비하는 경우가 종종 있습니다. “녹색 분야”프로젝트는 깨끗한 종이와 관련된 모든 예상 잠재력과 함께 흥미로울 수 있습니다. 엔지니어와 건축가 모두 try-this-itis의 희생양이 됩니다. 그들은 이달의 풍미 기술을 사용하기를 옹호하며, 새롭거나 멋진 것을 시도할 기회를 위해 특정 프로젝트에 적합하지 않을 수도 있다는 경고 신호를 무시합니다. 몇 달이 지나면 framework-du-jour는 더 이상 팀의 요구를 충족시키지 못하고 코드의 품질이 저하되고 있으며, 우리는 기술이 프로젝트의 열악한 결과에 대한 희생양이되는 부분으로 돌아갑니다.
결국 중요한 것은 TDD를 촉진하는 데 사용되는 기술, 방법론 또는 프레임워크가 팀과 비즈니스를 위해 작동한다는 것입니다. 당신이 당신의 도구에 의해 방해를 받는다면, 그들은 가치를 더하지 않을 뿐만 아니라, 적극적으로 당신을 상대로 일하고 있습니다. 사용하려는 프레임워크를 철저히 평가하고, 사용 방법을 정확히 이해하는 데 시간을 할애하십시오. 이 접근 방식은 TDD와 관련된 의사 결정뿐만 아니라 모든 설계 의사 결정에도 적용됩니다.
마무리
간단히 말해, TDD와 같은 아이디어는 단순히 코드베이스에 버그가 나타나지 않도록 방지하는 기술이 아니라 보다 편리한 방식으로 피드백을 수집하는 프레임워크를 제공하는 것입니다. 어떤 접근 방식을 선택하든 중요한 것은 비즈니스와 소프트웨어가 변화하는 추세와 비즈니스 요구 사항에 보다 빠르게 적응할 수 있도록 하는 것입니다. 그 과정에서 TDD와 TDD의 대응 요소가 단순히 개발 팀에 구현하도록 요청한 다음 잊어버릴 수 있는 것이 아니며, 이러한 기술을 효과적으로 활용하려면 프레임워크 및 도구와 같은 구현 세부 사항을 살펴보기 전에 문화적 수준에서 접근법을 수용하고 활성화하는 데 주의를 기울여야 합니다.
