테스트 주도 개발(TDD)이란 무엇인가요?

개발자는 각 테스트를 통과할 수 있을 만큼 충분한 코드를 작성한 다음 테스트와 코드를 모두 개선한 후 새 테스트와 새 기능으로 이동합니다.

테스트 주도 개발은 본질적으로 개발자가 더 짧은 피드백 주기를 통해 코딩의 속도를 늦추고 코드를 검증 및 개선하도록 합니다. 필수는 아니지만 DevOps 팀은 초보자부터 노련한 전문가까지 코더에게 다양한 프로그래밍 언어에서 TDD를 사용하도록 권장합니다. 예를 들어, Java, Python 등과 애플리케이션 프로그래밍 인터페이스(API)와 프로그램 애플리케이션에서 TDD를 사용하도록 합니다.

이 스타일의 프로그래밍은 코딩, 테스트(자동화된 단위 수준 테스트 형태) 및 코드 디자인 간의 관계를 강화합니다. 테스트 주도 개발은 초기 개발 시간을 늘릴 수 있지만 코드 기능과 민첩성을 개선하고 전반적인 시간을 절약하는 것으로 입증되었습니다.

TDD를 사용하는 개발자는 오류를 즉시 식별하고 해결함으로써 작은 문제가 더 큰 문제로 발전하는 것을 방지할 수 있습니다. 테스트 주도 개발은 개발자가 코드를 검증하고 개선하도록 하므로 최종 품질 확인과 수정이 간소화됩니다. 

대체 테스트 프레임워크에는 모든 자동화된 테스트를 작성하기 전에 프로덕션 코드를 작성하거나 프로덕션 코드를 작성하기 전에 전체 테스트 스위트를 작성하는 것이 포함됩니다. 이러한 방법은 반드시 비효율적인 것은 아니지만, 특히 규모가 크고 복잡한 프로젝트에서는 필수 디버깅 시간을 늘리는 것으로 나타났습니다.

테스트 주도 개발은 일반적으로 새로운 프로덕션 코드를 만드는 데 사용되지만 이전 기술이나 다른 기술로 개발된 레거시 코드의 디버깅을 개선하는 데에도 자주 적용됩니다. 

테스트 주도 개발은 개발보다 테스트를 우선시하여 기존 개발 프로세스를 역전시킵니다. 반복적인 접근 방식인 테스트 주도 개발은 단위 수준에서 고품질 코드를 생성하는 테스트 가능한 워크플로를 촉진하여 코드 품질과 가독성을 개선합니다. 개발자는 단위 테스트를 구현할 때 개별 알고리즘과 같은 논리의 작은 부분에 집중합니다. 테스트를 통과하도록 특별히 코드를 작성하면 더 깔끔하고 내구성 있는 코드을 만들 뿐만 아니라 문서를 개선하는 데 도움이 됩니다. 

테스트 주도 개발에는 두 가지 주요 수준이 있습니다.

인수 TDD(행동 주도 개발(BDD)이라고도 함)의 경우 프로그래머는 하나의 인수 테스트를 작성한 다음 이를 통과하기에 충분한 새 코드를 작성합니다. 인수 테스트는 고객 테스트 또는 고객 인수 테스트라고도 합니다.

이 테스트는 일반적으로 제품 이해 관계자가 설명한 최소 기능에 필요한 테스트 사례로 이해할 수 있습니다. ATDD는 상세하고 실행 가능한 요구 사항을 식별하기 위해 노력합니다. 인수 테스트는 Fitnesse 또는 RSpec과 같은 다양한 테스트 도구를 사용하여 수행할 수 있습니다.

간단히 TDD라고도 하는 개발자 TDD는 코더가 ATDD 테스트에 대한 자체 솔루션을 평가하기 위해 단일 테스트를 작성하도록 합니다. 개발자 TDD는 JUnit이나 VBUnit과 같은 테스트 자동화 도구를 사용합니다. 

테스트 주도 개발 전략을 사용할 때 코더는 먼저 소프트웨어의 각 개별 요소 또는 기능을 확인하는 테스트를 작성하여 해당 개별 테스트를 통과할 수 있는 충분한 코드를 작성합니다. 소프트웨어가 완성되면 다시 테스트를 거치고, 테스트에 통과하면 코드를 개선하여( 리팩토링이라고 하는 프로세스) 필수 요소만 포함시킵니다. 그런 다음 개발자는 이후의 각 소프트웨어 기능에 대해 이 과정을 반복합니다. 

테스트 주도 개발 프로세스는 5가지 개별 단계로 나뉩니다.

1. 개발자는 특정 소프트웨어 기능에 대한 코드를 작성하기 전에 먼저 해당 기능에 대한 개별 단위 테스트를 작성합니다.
2. 그런 다음 개발자는 코드를 실행하지만 코드 함수가 아직 작성되지 않았기 때문에 실패해야 합니다. 이 단계는 테스트 자체가 작동하고 오탐을 반환하지 않는지 확인하는 데 중요합니다. 코드가 통과하면 테스트를 다시 작성해야 함을 나타냅니다.
3. 프로그램이 테스트에 실패하면 개발자는 테스트를 통과할 수 있을 만큼의 추가 소프트웨어 코드만 작성합니다. 
4. 코드가 테스트를 통과할 수 있는 경우 단순성을 위해 테스트와 코드가 모두 리팩토링되고 불필요한 코드를 제거합니다. 
5. 충분히 리팩토링된 소프트웨어가 리팩토링된 테스트를 통과할 수 있으면 개발자는 다음으로 원하는 소프트웨어 기능으로 이동합니다. 그런 다음 테스터는 각각의 새로운 기능에 대한 테스트를 작성하고 실행합니다. 

간단히 말해서, 테스트 주도 개발 프로세스는 레드-그린-리팩터링 주기라고 하는 반복 가능한 루프를 따릅니다. 주기의 단계는 다음과 같습니다.

• 레드: 의도한 소프트웨어 동작에 대한 실패 테스트를 작성합니다. 

• 그린: 테스트를 통과할 수 있을 만큼 추가로 작성합니다.

• 리팩토링: 테스트를 통과하면서 최대한 단순성 표준을 충족하도록 코드를 개선합니다.

테스트 주도 개발의 구체적인 기원은 알려져 있지 않지만 테스트를 먼저 작성하고 프로덕션 코드를 두 번째로 작성한다는 개념은 1990년대 중반까지 일반적인 관행이 아니었습니다. 그 전에는 테스트 프레임워크에서 개발자를 자체 코드베이스 테스트와 분리했습니다. 그러나 소프트웨어 엔지니어링이 발전함에 따라 DevOps 팀은 특히 빠르게 변화하는 이해 관계자의 요구 사항을 처리할 때 이해 관계자의 요구를 충족하기 위해 더 빠르고 유연한 방법론이 필요했습니다. 

테스트 주도 개발은 다양한 새로운 테스트 프레임워크에서 발전했으며 다양한 다른 프레임워크에도 모듈식 구성 요소로 채택되었습니다. 특히 TDD는 개발자의 소프트웨어 품질과 개발자의 삶의 질을 모두 향상시키기 위해 개발된 민첩한 소프트웨어 개발 프레임워크인 익스트림 프로그래밍(XP)의 개념에 포함되어 있습니다.

민첩성 커뮤니티의 주요 인물이자 익스트림 프로그래밍의 창시자인 소프트웨어 엔지니어 Kent Beck은 테스트 주도 개발을 '재발견'한 공로를 인정받고 있습니다. Beck의 말에 따르면: 

"TDD에 대한 원래 설명은 프로그래밍에 관한 아주 오래된 책에 있었습니다. 그 책에서는 입력 테이프를 가져와 예상한 아웃풋 테이프를 수동으로 입력한 다음 실제 아웃풋 테이프가 예상 아웃풋과 일치할 때까지 프로그래밍하라고 했습니다. Smalltalk에서 첫 번째 xUnit 프레임워크를 작성한 후 이 글을 읽은 기억이 나서 사용해 보았습니다. 이것이 바로 TDD의 기원이었습니다. 나이든 프로그래머에게 TDD에 대해 설명할 때 저는 종종 이런 말을 듣곤 합니다. "물론이죠. 그렇지 않으면 어떻게 프로그래밍을 할 수 있을까요?" 따라서 저는 제 역할을 TDD '재발견'이라고 부릅니다." 

테스트 주도 개발의 발전 과정에서 주목할 만한 시기는 다음과 같습니다.

• 1976년: Glenford Myers는 Software Reliability를 출판하여 "개발자는 자신의 코드를 테스트해서는 안 된다"고 주장합니다. Myers가 이 개념의 창시자는 아니었을지 모르지만, 그의 연구는 앞으로 몇 년 동안 널리 퍼질 일반적인 개념에 신빙성을 부여했습니다. 

• 1990년:  1990년대 초에는 '블랙박스' 기법이 소프트웨어 테스트를 지배했습니다. 이러한 종류의 테스트 프레임워크에서 테스터는 소프트웨어를 마치 뚫을 수 없고 알 수 없는 '블랙박스'처럼 취급합니다. 블랙박스 테스트는 소프트웨어의 내부 작동 방식에 대한 지식이 전혀 없는 테스터를 고용합니다. 

• 1994년: Kent Beck이 Smalltalk 테스트 프레임워크인 SUnit을 개발하여 코드베이스 최적화를 위한 테스트 우선 접근 방식의 기초를 마련했습니다. 

• 1999–2002년: 민첩한 개발 운동이 활성화되면서 Kent Beck은 익스트림 프로그래밍 개념을 개발하고 테스트 주도 개발을 체계화하며 모의 객체라는 중요한 개념을 소개했습니다. TDD는 모의 객체를 사용하여 테스트 중에 실제 종속성(예: 데이터베이스, 외부 서비스 등)의 동작을 시뮬레이션합니다. 이이 방법을 사용하면 개발자는 정확하게 수행되도록 할 수 있으며 유지 관리할 수 있는 모의 개체에 테스트 코드를 집중할 수 있습니다. 모의 개체를 사용하는 실패한 테스트는 잠재적으로 잘못 구성된 종속성을 실패의 원인으로 판단하고 제거할 수 있습니다. 

• 2003년: Kent Beck은 Test Driven Development: By Example를 출간하여, 광범위한 개발 커뮤니티에서 관행을 대중화하고 개발자 주도 테스트의 정당성을 더 높였습니다. 

익스트림 프로그래밍의 구성 요소인 테스트 주도 개발은 더 나은 코드를 만드는 것뿐만 아니라 더 뛰어난 코더가 되는 것에도 도움이 되는 것으로 밝혀졌습니다. TDD를 통해 코더는 프로젝트에 대한 더 나은 인사이트를 얻고 프로그램 설계를 추진할 수 있습니다. 개발자는 각 기능을 구현하기 전에 테스트 케이스를 중심으로 클라이언트 또는 사용자가 함수를 사용하는 방식을 시각화해야 합니다. 이 접근 방식은 구현 전에 제품 인터페이스를 배치하고 개발자가 더 사용자 중심적인 애플리케이션을 만들 수 있도록 합니다. 

테스트 주도 개발의 몇 가지 추가 이점은 다음과 같습니다.

• 포괄적인 테스트 범위: TDD는 모든 코드가 최소한 하나의 테스트로 다루어지도록 보장하기 때문에 사양 또는 문서 도구라고도 합니다. 

• 문서화 개선: TDD가 포괄적인 범위를 제공하는 것과 같은 이유로 강력한 문서와 사양도 제공합니다. 이 시스템은 개발자, 프로젝트 관리자 및 기타 이해 관계자가 코드 기능과 요구 사항을 검증하고 프로젝트 라이프사이클 동안 질서를 확립하는 데 도움이 됩니다. 

• 자신감 향상: TDD를 사용하는 개발자와 DevOps 팀은 코드뿐만 아니라 테스트에 대해서도 더 큰 자신감을 얻습니다. 

• 지속적인 통합 촉진: TDD는 라이브 코드가 새로운 기능과 패치로 지속적으로 업데이트되는 지속적 통합 관행에 적합합니다. 

• 디버깅 감소: TDD는 개발 프로세스에서 테스트를 우선적으로 수행하므로 개발 막바지에 광범위한 디버깅을 수행할 필요가 줄어듭니다. 

• 요구 사항 명확성 향상: TDD는 개발자가 작업을 시작하기 전에 각 특정 프로그램 요구 사항을 명확하게 이해하는 데 도움이 됩니다. 

• 생산성 향상: TDD는 대규모 프로젝트를 더 작고 달성 가능한 단계로 세분화하는 데 도움이 되므로 개발자의 생산성 향상과 관련이 있는 경우가 많습니다. 

• 단순한 디자인 강화: 그린-레드-리팩토링 TDD 주기의 중요한 세 번째 단계에서 개발자는 코드를 리팩토링하고 단순화해야 합니다. 이 방법은 일반적인 단순성과 디자인의 품질을 개선합니다. 

• 멘탈 모델 강화: TDD는 모든 고유한 기능이나 요구 사항을 검토하고 통합함으로써 코더가 현재 작업 중인 코드의 강력한 멘탈 모델을 개발하는 데 도움이 됩니다. 이 멘탈 모델은 개발자가 작업 중에 코드의 전반적인 기능과 요구 사항을 시각화하는 데 도움이 됩니다. 

• 시스템 안정성 향상: 테스트 주도 개발을 사용하면 설계의 단순성을 위한 높은 표준에 부합하며 강력하고 잘 테스트된 코드를 생성하여 전반적인 애플리케이션 안정성을 향상시키는 것으로 입증되었습니다. 

(테스트 주도 개발TDD)를 사용하면 많은 중요한 이점이 있지만 문제가 없는 것은 아닙니다. 이러한 문제의 심각도는 프로젝트에 따라 달라지거나 다양한 다른 기술로 완화될 수 있지만 TDD의 몇 가지 단점은 다음과 같습니다.

• 코드 볼륨 증가: TDD에서는 코더가 필요한 각 기능에 대한 코드를 작성할 뿐만 아니라 각 기능에 대한 테스트도 요구합니다. 제품 코드와 함께 테스트 코드를 추가하면 전체 코드베이스가 커집니다. 

• 잘못된 자신감: 각 기능이 테스트를 통과하기 위해 작성되기 때문에 코더와 프로젝트 관리자는 전체 코드의 기능에 대한 잘못된 보안 의식을 갖게 될 수 있습니다. 통합된 각 기능을 테스트하더라도 TDD는 최종 품질 관리 및 API 테스트의 필요성을 대체하지 않습니다. 

• 오버헤드 증가: TDD를 사용하려면 코더는 프로덕션 코드 외에도 대규모 테스트 스위트를 유지 관리해야 합니다. 테스트 코드베이스를 유지 관리하려면 일정량의 리소스가 필요하며 간접비가 추가될 수 있습니다. 

• 효율성 감소: TDD는 생산성을 향상시키는 것으로 나타났지만 각각의 새로운 기능을 만들고 구현하는 데 더 많은 단계가 추가되므로 프로젝트 개발이 지연될 수 있습니다. 

• 설정 시간 증가: TDD를 사용하려면 개발자가 코드에 적합한 테스트 환경을 설정하고 유지 관리해야 합니다. 

• 전체 디자인 무시: TDD는 코드 단순성과 향상된 디자인을 장려하지만 개별 구성 요소에 너무 집중하면 전체 코드의 조화가 떨어질 수 있습니다. TDD를 사용하는 코더는 개별 기능 업데이트가 중요한 애플리케이션에 컴파일될 때 어떻게 통합되는지 알아야 합니다.