[첫번째 프로젝트] 16. TDD, BDD

이번 장을 읽기 전, 소프트웨어 개발 방법론의 내용을 한 번 읽은 후에 해당 내용을 읽는 것을 권장합니다.

1. 소프트웨어 개발 방법론

소프트웨어 개발 방법론은 소프트웨어를 개발하기 위한 '구체적인 절차, 방법, 기술 등을 정리'한 것입니다. 이를 통해 개발자들이 프로젝트를 효율적으로 관리하고 소프트웨어를 더욱 품질 높게 개발할 수 있도록 도와줍니다.

소프트웨어 개발방법론으로는 대표적으로는 폭포수 모델 (Waterfall Model), 애자일 방법론 (Agile Methodologies), 린(Lean) 등이 있습니다.

[참고] 개발 방법론 종류

개발 방법론	특징
폭포수 모델(Waterfall Model)	순차적 개발 과정, 각 단계를 선행적으로 진행
애자일 방법론(Agile Methodologies)	반복적이고 점진적인 개발 방법, 유연성과 빠른 적응력을 갖춤
린(Lean)	낭비를 최소화하고 효율적인 생산 방식을 추구
스파이럴(Spiral)	점진적이고 반복적인 개발 방법, 위험 분석과 평가를 강조
라디칼(RAD)	짧은 시간 내에 빠른 개발을 목표로 함
프로토타이핑(Prototyping)	초기 모델을 만들어 피드백을 받고 개선하는 과정으로 개발을 진행

2. TDD

TDD(Test-Driven-Development)는 소프트웨어 개발 방법론 중 하나로 ‘테스트 주도 개발’을 의미합니다.

코드를 작성하기 이전에 '테스트 케이스를' 작성하고 테스트를 통과하기 위한 그에 맞는 기능을 작성합니다. 테스트 중에 실패한 코드에 대해서는 수정해 나아가면서 '반복적인 테스트'를 통한 개발을 하는 작업을 의미합니다.

• https://www.programonaut.com/a-practical-example-of-test-drive-development/

[ 더 알아보기 ]

• 테스트 케이스

  특정 기능 또는 시나리오를 테스트하기 위한 지침이 포함된 문서입니다. 테스트 케이스는 테스트를 수행하는 데 필요한 모든 정보를 제공하며, 테스트의 목적, 입력 데이터, 예상 결과 등을 명확하게 정의합니다.

• 테스트 케이스를 작성하는 자체가 TDD를 의미하는 것일까?

  테스트 케이스를 우선 작성하고 그 다음 코드를 입력하는 것이 TDD의 과정이지만, 코드를 우선 작성 후 그 다음 테스트를 하는것은 TDD가 아닙니다.

2.1 애자일 방법론 내에서 TDD 장점

애자일 방법론에는 대표적으로는 스크럼, 칸반, 익스트림 프로그래밍이 있습니다. 이러한 애자일 방법론 중 TDD는 익스트림 프로그래밍(Extreme Programming, XP)의 ‘실천 방법’ 중 하나로 사용되고 있습니다.

익스트림 프로그래밍은 TDD를 적극적으로 활용하는 개발 방법론 중 하나이지만 익스트림 프로그래밍에서만 TDD가 사용되는 것은 아닙니다.

[ 더 알아보기]

• 익스트림 프로그래밍(Extreme Programming, XP)

  익스트림 프로그래밍에서 고객과 개발자가 함께 일하며 고객이 원하는 기능을 우선순위에 따라 작은 단위로 나누어 개발을 합니다. 이를 통해 고객의 요구사항을 빠르게 반영하고 문제가 발생하였을 때 빠르게 대처할 수 있습니다.

• 실천 방법

  익스트림 프로그래밍(XP)의 일환으로 애자일 방법론에서 사용되는 방법들을 의미합니다.

• https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

익스트림 프로그래밍 방법론 중 실천 방법 중에 ‘Unit Test’ 과정에서 TDD를 이용하여서 수행을 합니다.

실천 방법	설명
Pair Programming	두 명의 프로그래머가 함께 작업하여 코드를 작성하는 방법입니다. 한 명이 코드를 작성하고, 다른 한 명이 코드를 검토하고 지속적인 피드백을 제공하며 협업합니다.
Unit Test	소프트웨어의 작은 부분인 유닛에 대한 테스트를 수행합니다. 유닛 테스트는 개별 함수 또는 모듈이 예상대로 작동하는지 확인하는 데 사용됩니다.
Pair Negotiation	두 명의 사람이 함께 협상하여 문제를 해결하고, 결정을 내리는 과정입니다. 각각의 의견을 고려하며 협업하여 최선의 결론을 도출합니다.
Stand-up Meeting	팀 구성원들이 매일 짧은 시간 동안 서로의 진행 상황과 장애물을 공유하는 미팅입니다. 팀의 커뮤니케이션과 협업을 도울 수 있는 기회가 제공됩니다.
Acceptance Test	소프트웨어가 요구사항을 만족하는지 확인하는 테스트입니다. 사용자의 관점에서 시스템을 검증하며 사용자 승인을 받을 수 있는지 확인합니다.
Iteration Plan	작은 주기로 소프트웨어를 개발하는 방법입니다. 각 이터레이션은 목표와 일정을 설정하고, 해당 이터레이션 동안 필요한 작업을 계획합니다.
Release Plan	소프트웨어 제품을 출시하기 위한 계획입니다. 기능 및 버그 수정 등의 작업을 포함하여 출시 일정과 전략을 계획합니다.

그럼 왜 익스트림 프로그래밍 방법론에서 TDD를 이용하는 것일까?

그럼 왜 익스트림 프로그래밍 방법론에서 TDD를 이용하는 것일까?

1. 품질 향상
   개발자는 코드의 동작을 확실히 이해하고 테스트 케이스를 통해 코드의 정확성을 검증할 수 있습니다. 이로 인해 좀 더 견고하고 안정적인 코드를 작성할 수 있습니다.

2. 리팩토링 지원

   TDD는 코드를 작은 단위로 분리하고 테스트 가능한 형태로 작성하는 것을 장려합니다. 이를 통해 코드의 구조와 설계를 개선하기 쉬워지며, 리팩토링 작업도 더욱 안전하게 수행할 수 있습니다.

3. 빠른 피드백

   TDD를 사용하면 개발자는 작은 단위의 테스트를 빠르게 실행하고 결과를 확인할 수 있습니다. 이를 통해 버그를 빠르게 발견하고 수정할 수 있으며, 코드 변경에 대한 피드백을 신속하게 받을 수 있습니다.

4. 협업 강화

   TDD는 테스트 코드가 개발 프로세스의 일부로써 문서화되므로, 다른 개발자들과의 협업을 용이하게 합니다. 테스트를 통한 코드의 동작 이해와 검증은 팀 내에서의 의사소통과 협업을 강화시킵니다.

익스트림 프로그래밍에서는 '요구사항을 빠르게 반영'하여 문제가 발생하였을 때 '빠르게 대처'하는 원칙을 가지고 있습니다. 그리고 이러한 과정이 반복이 되면서 하나의 상품으로 구성이 됩니다.

2.2 TDD 수행 과정

TDD 수행 과정

• 테스트 작성(Write Test) - 실패하는 테스트 실행 (Test Fails) - 코드 작성(Write Code) - 테스트 통과(Test Passes) - 리팩토링(Refactor)과 같은 반복 과정으로 수행이 됩니다.

• https://medium.com/@luisfmachado/swift-test-driven-development-tdd-810add46a1b9

TDD 수행 과정

1. Write Test : 테스트 코드 작성

   • 구현하려는 기능이나 동작을 검증할 테스트 코드를 작성합니다.
   • 해당 단계에서 원하는 동작이 ‘실패하는 테스트 케이스’를 작성합니다.
     ex) add() 함수를 구성할 예정이고, 두 개의 숫자를 더하는 기능이 잘 수행되는지에 대해 테스트 코드를 작성합니다.

2. Test Fails : 실패하는 테스트 실행

   • 작성한 테스트를 실행하여 기대한 대로 동작하지 않는 것을 확인합니다.
   • 이때는 실패하는 테스트가 예상대로 동작하는 것입니다.
     ex) 아직 코드가 없기에 실패하는 테스트가 실행됩니다.

3. Write Code: 코드 작성

   • 실패하는 테스트를 통과할 수 있는 최소한의 코드를 작성합니다.
   • 이 단계에서는 테스트를 통과하는 것이 목표입니다.
     ex) add() 함수를 작성하여 두 개의 숫자를 더하는 코드를 작성합니다.

4. Test Passes: 테스트 통과

   • 작성한 코드가 테스트를 통과하는지 확인합니다.
   • 테스트가 성공적으로 통과되면 기능이 제대로 구현된 것으로 간주합니다.
     ex) 작성한 코드를 기반으로 두 개의 숫자를 더하는 테스트에 성공하는지 확인하며, 해당 단계에서는 반드시 테스트가 통과되어야 합니다.

5. Refactor: 리펙토링

   • 이전 과정에서 테스트를 통과한 코드를 개선하고 중복을 제거하며 코드의 가독성을 높이는 등의 작업을 수행합니다.
   • 기능의 동작에는 영향을 주지 않으며, 코드의 품질을 개선하는 단계입니다.
   • 작성한 코드를 개선하고 가독성과 유지보수성을 향상하기 위해 리팩토링 작업을 수행합니다.
     ex) 코드를 읽기 더 쉽고 유지보수 하기가 더 쉽도록 재 구성합니다.

결론적으로, TDD에서 가장 중요한 원칙은 ‘최소한의 코드’를 작성하여 ‘최소 단위 테스트를 통과’시켜 ‘점진적으로 코드’를 확장해 나아가는 것을 추구합니다. 또한, 처음부터 많은 로직의 코드를 작성하여 복잡성을 만들어 내기보다는 ‘점진적으로 확장해 나아가며 견고한 코드를 작성해 나아가는 것을 추구합니다.

2.3 TDD의 한계

개발 방법론 중 폭포수 개발 방법론과 TDD를 비교하였을 시 단기적으로는 초기투자 비용이 많이 들어가지만 추후 장기적으로 봤을 때는 효과를 크게 누릴 수 있었습니다.

Waterfall

Waterfall vs TDD

TDD의 한계

1. 시간과 노력

   TDD는 코드를 작성하기 전에 테스트 케이스를 먼저 작성해야 하므로, 이로 인해 개발 시간이 늘어날 수 있습니다. 또한, TDD를 위해선 기존에 비해 더 많은 코드를 작성해야 하므로 더 많은 노력이 필요합니다.

2. 설계에 대한 이해

   테스트 케이스를 작성하기 위해서는 개발자가 설계에 대한 깊은 이해를 가지고 있어야 합니다. 그렇지 않으면, 테스트 케이스가 미흡하게 작성될 수 있습니다.

3. 복잡한 시나리오의 테스트

   복잡한 시나리오나 UI, 성능 테스트 등은 TDD로 테스트하기 어려울 수 있습니다.

4. 변동이 많은 요구사항

   요구사항이 자주 바뀌는 경우, 테스트 케이스를 계속해서 수정해야 하는 상황이 발생할 수 있습니다.

3. BDD

BDD(Behavior Driven Development)는 소프트웨어 개발론 중 하나로 ‘행동 주도’ 개발 방법론을 의미합니다.

TDD에서 파생된 개발방법론으로 TDD에서 기능 중심의 '테스트케이스'를 작성하는데 한계를 극복하기 위해 등장하게 되었습니다. BDD에서는 ‘사용자의 행위’를 기반으로 ‘사용자 시나리오’를 구성하여 ‘테스트 케이스’를 작성하고 개발을 진행하는 방식입니다.

즉, ‘사용자의 행위’를 정의하고 행위에 따라 개발해 나아가는 방식을 의미합니다. 여기서 ‘사용자의 행위’는 기획자가 작성한 ‘요구사항’이나 ‘기획서’에 적혀 있는 내용 자체를 의미합니다.

3.1 BDD 수행 과정

• https://katalon.com/resources-center/blog/bdd-testing

BDD 수행 과정

1. 요구사항 명세화

   비즈니스 요구사항이나 기능 요구사항을 이해하고 분석하여 사용자의 행동을 중심으로 한 '시나리오를 작성'합니다.이 과정에서는 도메인 특정 언어를 사용하여 비개발자도 이해할 수 있는 방식으로 시나리오를 명세화합니다.

2. 테스트 케이스 작성

   작성된 시나리오를 기반으로 테스트 케이스를 작성합니다. 이때 테스트 케이스는 사용자의 행동 중심으로 작성되어야 합니다.

3. 테스트 수행

   작성된 테스트 케이스를 수행합니다. 이때 테스트는 실패하게 됩니다. 왜냐하면 테스트 케이스에 따른 기능이 아직 구현되지 않았기 때문입니다.

4. 코드 구현

   테스트 케이스를 통과시킬 수 있는 최소한의 코드를 구현합니다.

5. 테스트 확인

   구현된 코드가 테스트 케이스를 통과하는지 확인합니다. 통과하지 못할 경우 코드를 수정하여 테스트를 통과하도록 합니다.

6. 리팩토링

   코드를 개선하여 가독성을 높이고, 중복을 제거하며, 코드의 품질을 향상합니다.

4. 테스트 시나리오 작성: Given, When, Then

• 테스트 시나리오

  • 개발자가 작성하는 시나리오로 원하는 기능이 어떻게 동작해야 하는지를 명세하는 것을 의미합니다.
  • 테스트 케이스는 개별적인 테스트 단위로서, 특정 입력에 대한 기대된 출력을 확인하는 역할을 합니다.

• 테스트 시나리오 작성: Given, When, Then

  • ‘사용자의 행위’를 기반으로 ‘테스트 시나리오’를 구성하여 ‘테스트 케이스’를 구성하는 방법에 대해 알아봅니다.

• 즉 기획자가 작성한 ‘요구사항’이나 ‘기획서’에 적혀있는 내용들을 기반으로 테스트 시나리오를 구성하며 이를 기반으로 테스트 케이스를 구성합니다.

• https://tv.kakao.com/channel/3693125/cliplink/414004682

4.1 BDD 구조

BDD에서는 Given, When, Then이라는 구조를 사용하여 요구사항과 기능에 대해 테스트 시나리오를 정의합니다

1. Given(=주어진 환경)

• ‘사용자 행위’를 수행하기 위해 주어진 ‘환경’에 대해 서술합니다.
• 해당 단계에서는 시스템이나 애플리케이션의 초기 상태, 환경, 입력 등에 대해 서술합니다.
• ex) “사용자가 페이지에 접속해 있는 상황에서“

2. When(= 행위)

   • 실제 사용자 행위에 대해서 서술합니다.
   • 해당 단계에서는 시스템이나 애플리케이션 내에 발생하는 특정 조건이나 이벤트들에 대해 서술합니다.
   • ex) “사용자 아이디 필드에 ‘adjh54’을 입력하고 비밀번호 필드에 ‘12345’를 입력하고 ‘로그인’ 버튼을 누르면”

3. Then(= 기대결과)

   • 행위에 따른 기대결과를 서술합니다.
   • 해당 단계에서는 예상되는 동작이 실제로 발생하는지 확인하고 기대한 결과가 나오는지에 대한 검증을 수행하여 서술합니다.
   • ex) “로그인이 성공하고 메인 페이지로 이동한다”

• 최종적으로 아래의 테스트 시나리오가 나오게 됩니다.

  “사용자가 페이지에 접속해 있는 상황에서(Given)”, “사용자 아이디 필드에 ‘adjh54’을 입력하고 비밀번호 필드에 ‘12345’를 입력하고 ‘로그인’ 버튼을 누르면(When)”, “로그인이 성공하고 메인 페이지로 이동한다(Then)”

5. TDD와 BDD의 상호보완적 관계

TDD와 BDD의 가장 큰 차이점은 아래와 같습니다.

• TDD의 테스트 케이스

  • ‘기능’을 확인하기 위한 목적으로 작성을 합니다.
  • ex) 계산기 기능을 만들었다고 가정하였을 때, add 함수의 파라미터로 1과 1이 들어갔을 경우 2의 값이 나오는지에 대해 확인합니다.

• BDD의 테스트 케이스

  • - 시나리오를 주체로 한 ‘행위’를 확인하기 위한 관점에서 작성을 합니다.
  • ex) 계산기 기능을 만들었다고 가정하였을 때, 사용자가 ‘1’ 버튼을 클릭하고 ‘+’ 버튼을 클릭하고 ‘1’ 버튼을 클릭했을 때 화면상에 ‘2’가 표시가 되는지를 확인합니다.

위에서 언급했듯이 BDD는 TDD에 파생된 개념 중 하나입니다. 그렇기에 선택이 아닌 서로 간은 상호 보완적인 관계입니다.

• TDD의 관점: TDD에서 보기 어려운 ‘유저 시나리오’ 관점을 확인할 수 있습니다.

• BDD의 관점: BDD에서 보기 어려운 TDD 테스트 케이스를 통해 모듈들을 테스트 커버리지를 극복이 가능합니다.

• https://tv.kakao.com/channel/3693125/cliplink/414004682

아래는 TDD와 BDD의 동작 사이클입니다.

• BDD가 수행되기 위해서는 TDD 사이클이 함께 더해지는 구조로 이루어집니다.

• BDD의 사이클이 통과해야 하고 TDD도 함께 통과를 해야 하나의 테스트 구조가 완료가 됩니다.

• https://tv.kakao.com/channel/3693125/cliplink/414004682

6. TDD와 BDD를 적용할 때의 가장 큰 장점

TDD와 BDD를 적용할 때의 가장 큰 장점은 아래와 같이 기획 → 설계 → 코드 작성의 과정을 거치며 구성을 하는 도중에 큰 변화가 필요한 문제가 발생하는 ‘기회 누락 발견’이 발생할 수 있습니다.

기획이나 설계단계에서 누락된 기능이 발생하여 코드 개발을 변경하는 과정이 발생합니다.

• https://tv.kakao.com/channel/3693125/cliplink/414004682

그렇기에 아래와 같이 TDD에서는 기획 - 설계 단계에 ‘테스트 케이스’를 작성하여 사전에 ‘예외 케이스’를 찾아서 발견하여 추후에 발생하는 문제에 대해 줄일 수 있습니다. 시나리오 작성 시 사전에 이슈를 발견할 수 있습니다.

• https://tv.kakao.com/channel/3693125/cliplink/414004682

7. TDD, BDD 최종 정리

TDD와 BDD는 목적에 따라서 사용여부를 결정해야 합니다. 또한 각각의 장단점에 대해 알고 개발방법론으로 적합한지에 대해 판단하여 사용하여야 합니다.

분류	TDD (테스트 주도 개발)	BDD (행동 주도 개발)
정의	테스트가 개발의 중심이 되는 개발 방식. 먼저 테스트를 작성하고 그 테스트를 통과하는 코드를 작성함으로써 소프트웨어의 품질을 높이는 방법론	행동을 기반으로 테스트를 작성하는 방법론. 사용자의 행동이나 시스템의 반응을 기반으로 테스트를 작성함으로써 소프트웨어의 품질을 높이고 사용자 중심의 개발을 가능하게 함
목적	기능 동작의 검증, 코드의 품질 향상	서비스 유저 시나리오 동작의 검증, 사용자 중심의 개발
설계 중심	제공할 모듈의 기능 중심 설계	서비스 사용자 행위 중심 설계
테스트 코드 설계 주체	모듈 사양 문서(개발자가 작성)	서비스 기획서(서비스 기획자가 작성)
적합한 프로젝트	모듈/라이브러리 프로젝트	서비스 프로젝트
장점	코드의 결함을 미리 찾아내고, 코드의 품질을 보장. 코드의 리팩토링과 유지보수가 쉬움	사용자의 관점에서 테스트를 작성하여 사용자 중심의 개발을 가능하게 함
단점	테스트 작성에 시간이 많이 소요될 수 있음	사용자 행동에 대한 정확한 이해가 필요함