반응형
해당 글에서는 개발방법론 중 TDD, BDD에 대해 이해를 돕기 위한 목적으로 작성한 글입니다.
1) 소프트웨어 개발 방법론
💡 소프트웨어 개발 방법론
- 소프트웨어를 개발하기 위한 '구체적인 절차, 방법, 기술 등을 정리'한 것입니다. 이를 통해 개발자들이 프로젝트를 효율적으로 관리하고 소프트웨어를 더욱 품질 높게 개발할 수 있도록 도와줍니다.
- 소프트웨어 개발방법론으로는 대표적으로는 폭포수 모델 (Waterfall Model), 애자일 방법론 (Agile Methodologies), 린(Lean) 등이 있습니다.
💡 [참고] 개발 방법론 종류
| 개발 방법론 | 특징 |
| 폭포수 모델(Waterfall Model) | 순차적 개발 과정, 각 단계를 선행적으로 진행 |
| 애자일 방법론(Agile Methodologies) | 반복적이고 점진적인 개발 방법, 유연성과 빠른 적응력을 갖춤 |
| 린(Lean) | 낭비를 최소화하고 효율적인 생산 방식을 추구 |
| 스파이럴(Spiral) | 점진적이고 반복적인 개발 방법, 위험 분석과 평가를 강조 |
| 라디칼(RAD) | 짧은 시간 내에 빠른 개발을 목표로 함 |
| 프로토타이핑(Prototyping) | 초기 모델을 만들어 피드백을 받고 개선하는 과정으로 개발을 진행 |
[개발방법론] 소프트웨어 개발 방법론 : 폭포수(Waterfall), 애자일(Agile), 린(Lean) 방법론
해당 글에서는 소프트웨어 개발방법론에 대해 이해하고 각각의 종류에 대해 이해를 돕기 위해 작성한 글입니다. 1) 소프트웨어 개발방법론 💡 소프트웨어 개발 방법론 이란? - 소프트웨어를 개
adjh54.tistory.com
2) TDD(Test Driven Development, 테스트 주도 개발)
💡 TDD(Test-Driven-Development)
- 소프트웨어 개발 방법론 중 하나로 ‘테스트 주도 개발’을 의미합니다.
- 코드를 작성하기 이전에 '테스트 케이스를' 작성하고 테스트를 통과하기 위한 그에 맞는 기능을 작성합니다. 테스트 중에 실패한 코드에 대해서는 수정해 나아가면서 '반복적인 테스트'를 통한 개발을 하는 작업을 의미합니다.
[ 더 알아보기 ]
💡 테스트 케이스
- 특정 기능 또는 시나리오를 테스트하기 위한 지침이 포함된 문서입니다. 테스트 케이스는 테스트를 수행하는 데 필요한 모든 정보를 제공하며, 테스트의 목적, 입력 데이터, 예상 결과 등을 명확하게 정의합니다.
💡 테스트 케이스를 작성하는 자체가 TDD를 의미하는 것일까?
- 테스트 케이스를 우선 작성하고 그 다음 코드를 입력하는 것이 TDD의 과정이지만, 코드를 우선 작성 후 그 다음 테스트를 하는것은 TDD가 아닙니다.
1. 애자일 방법론 내에서 TDD : TDD 장점
💡 애자일 방법론 내에서 TDD : TDD 장점
- 애자일 방법론에는 대표적으로는 스크럼, 칸반, 익스트림 프로그래밍이 있습니다. 이러한 애자일 방법론 중 TDD는 익스트림 프로그래밍(Extreme Programming, XP)의 ‘실천 방법’ 중 하나로 사용되고 있습니다.
- 익스트림 프로그래밍은 TDD를 적극적으로 활용하는 개발 방법론 중 하나이지만 익스트림 프로그래밍에서만 TDD가 사용되는 것은 아닙니다.
[ 더 알아보기]
💡 익스트림 프로그래밍(Extreme Programming, XP)
- 익스트림 프로그래밍에서 고객과 개발자가 함께 일하며 고객이 원하는 기능을 우선순위에 따라 작은 단위로 나누어 개발을 합니다. 이를 통해 고객의 요구사항을 빠르게 반영하고 문제가 발생하였을 때 빠르게 대처할 수 있습니다.
💡 실천 방법
- 익스트림 프로그래밍(XP)의 일환으로 애자일 방법론에서 사용되는 방법들을 의미합니다.
💡 익스트림 프로그래밍 방법론 중 실천 방법 중에 ‘Unit Test’ 과정에서 TDD를 이용하여서 수행을 합니다.
| 실천 방법 | 설명 |
| Pair Programming | 두 명의 프로그래머가 함께 작업하여 코드를 작성하는 방법입니다. 한 명이 코드를 작성하고, 다른 한 명이 코드를 검토하고 지속적인 피드백을 제공하며 협업합니다. |
| Unit Test | 소프트웨어의 작은 부분인 유닛에 대한 테스트를 수행합니다. 유닛 테스트는 개별 함수 또는 모듈이 예상대로 작동하는지 확인하는 데 사용됩니다. |
| Pair Negotiation | 두 명의 사람이 함께 협상하여 문제를 해결하고, 결정을 내리는 과정입니다. 각각의 의견을 고려하며 협업하여 최선의 결론을 도출합니다. |
| Stand-up Meeting | 팀 구성원들이 매일 짧은 시간 동안 서로의 진행 상황과 장애물을 공유하는 미팅입니다. 팀의 커뮤니케이션과 협업을 도울 수 있는 기회가 제공됩니다. |
| Acceptance Test | 소프트웨어가 요구사항을 만족하는지 확인하는 테스트입니다. 사용자의 관점에서 시스템을 검증하며 사용자 승인을 받을 수 있는지 확인합니다. |
| Iteration Plan | 작은 주기로 소프트웨어를 개발하는 방법입니다. 각 이터레이션은 목표와 일정을 설정하고, 해당 이터레이션 동안 필요한 작업을 계획합니다. |
| Release Plan | 소프트웨어 제품을 출시하기 위한 계획입니다. 기능 및 버그 수정 등의 작업을 포함하여 출시 일정과 전략을 계획합니다. |
💡 그럼 왜 익스트림 프로그래밍 방법론에서 TDD를 이용하는 것일까?
1. 품질 향상
- 개발자는 코드의 동작을 확실히 이해하고 테스트 케이스를 통해 코드의 정확성을 검증할 수 있습니다. 이로 인해 좀 더 견고하고 안정적인 코드를 작성할 수 있습니다.
2. 리팩토링 지원
- TDD는 코드를 작은 단위로 분리하고 테스트 가능한 형태로 작성하는 것을 장려합니다. 이를 통해 코드의 구조와 설계를 개선하기 쉬워지며, 리팩토링 작업도 더욱 안전하게 수행할 수 있습니다.
3. 빠른 피드백
- TDD를 사용하면 개발자는 작은 단위의 테스트를 빠르게 실행하고 결과를 확인할 수 있습니다. 이를 통해 버그를 빠르게 발견하고 수정할 수 있으며, 코드 변경에 대한 피드백을 신속하게 받을 수 있습니다.
4. 협업 강화
TDD는 테스트 코드가 개발 프로세스의 일부로써 문서화되므로, 다른 개발자들과의 협업을 용이하게 합니다. 테스트를 통한 코드의 동작 이해와 검증은 팀 내에서의 의사소통과 협업을 강화시킵니다.
- 익스트림 프로그래밍에서는 '요구사항을 빠르게 반영'하여 문제가 발생하였을 때 '빠르게 대처'하는 원칙을 가지고 있습니다. 그리고 이러한 과정이 반복이 되면서 하나의 상품으로 구성이 됩니다.
2. TDD 수행 과정
💡 TDD 수행 과정
- 테스트 작성(Write Test) - 실패하는 테스트 실행 (Test Fails) - 코드 작성(Write Code) - 테스트 통과(Test Passes) - 리팩토링(Refactor)과 같은 반복 과정으로 수행이 됩니다.
💡 TDD 수행 과정
1. Write Test : 테스트 코드 작성
- 구현하려는 기능이나 동작을 검증할 테스트 코드를 작성합니다.
- 해당 단계에서 원하는 동작이 ‘실패하는 테스트 케이스’를 작성합니다.
ex) add() 함수를 구성할 예정이고, 두 개의 숫자를 더하는 기능이 잘 수행되는지에 대해 테스트 코드를 작성합니다.
2. Test Fails : 실패하는 테스트 실행
- 작성한 테스트를 실행하여 기대한 대로 동작하지 않는 것을 확인합니다.
- 이때는 실패하는 테스트가 예상대로 동작하는 것입니다.
ex) 아직 코드가 없기에 실패하는 테스트가 실행됩니다.
3. Write Code: 코드 작성
- 실패하는 테스트를 통과할 수 있는 최소한의 코드를 작성합니다.
- 이 단계에서는 테스트를 통과하는 것이 목표입니다.
ex) add() 함수를 작성하여 두 개의 숫자를 더하는 코드를 작성합니다.
4. Test Passes: 테스트 통과
- 작성한 코드가 테스트를 통과하는지 확인합니다.
- 테스트가 성공적으로 통과되면 기능이 제대로 구현된 것으로 간주합니다.
ex) 작성한 코드를 기반으로 두 개의 숫자를 더하는 테스트에 성공하는지 확인하며, 해당 단계에서는 반드시 테스트가 통과되어야 합니다.
5. Refactor: 리펙토링
- 이전 과정에서 테스트를 통과한 코드를 개선하고 중복을 제거하며 코드의 가독성을 높이는 등의 작업을 수행합니다.
- 기능의 동작에는 영향을 주지 않으며, 코드의 품질을 개선하는 단계입니다.
- 작성한 코드를 개선하고 가독성과 유지보수성을 향상하기 위해 리팩토링 작업을 수행합니다.
ex) 코드를 읽기 더 쉽고 유지보수 하기가 더 쉽도록 재 구성합니다.
💡 결론적으로, TDD에서 가장 중요한 원칙은 ‘최소한의 코드’를 작성하여 ‘최소 단위 테스트를 통과’시켜 ‘점진적으로 코드’를 확장해 나아가는 것을 추구합니다.
💡 또한, 처음부터 많은 로직의 코드를 작성하여 복잡성을 만들어 내기보다는 ‘점진적으로 확장해 나아가며 견고한 코드를 작성해 나아가는 것을 추구합니다.
3. TDD의 한계
💡 개발 방법론 중 폭포수 개발 방법론과 TDD를 비교하였을 시 단기적으로는 초기투자 비용이 많이 들어가지만 추후 장기적으로 봤을 때는 효과를 크게 누릴 수 있었습니다.
💡 Waterfall
💡 Waterfall vs TDD
💡 TDD의 한계
1. 시간과 노력
- TDD는 코드를 작성하기 전에 테스트 케이스를 먼저 작성해야 하므로, 이로 인해 개발 시간이 늘어날 수 있습니다. 또한, TDD를 위해선 기존에 비해 더 많은 코드를 작성해야 하므로 더 많은 노력이 필요합니다.
2. 설계에 대한 이해
- 테스트 케이스를 작성하기 위해서는 개발자가 설계에 대한 깊은 이해를 가지고 있어야 합니다. 그렇지 않으면, 테스트 케이스가 미흡하게 작성될 수 있습니다.
3. 복잡한 시나리오의 테스트
- 복잡한 시나리오나 UI, 성능 테스트 등은 TDD로 테스트하기 어려울 수 있습니다.
4. 변동이 많은 요구사항
- 요구사항이 자주 바뀌는 경우, 테스트 케이스를 계속해서 수정해야 하는 상황이 발생할 수 있습니다.
3) BDD(Behavior Driven Development, 행동 주도 개발)
💡 BDD(Behavior Driven Development)
- 소프트웨어 개발론 중 하나로 ‘행동 주도’ 개발 방법론을 의미합니다.
- TDD에서 파생된 개발방법론으로 TDD에서 기능 중심의 '테스트케이스'를 작성하는데 한계를 극복하기 위해 등장하게 되었습니다. BDD에서는 ‘사용자의 행위’를 기반으로 ‘사용자 시나리오’를 구성하여 ‘테스트 케이스’를 작성하고 개발을 진행하는 방식입니다.
- 즉, ‘사용자의 행위’를 정의하고 행위에 따라 개발해 나아가는 방식을 의미합니다. 여기서 ‘사용자의 행위’는 기획자가 작성한 ‘요구사항’이나 ‘기획서’에 적혀 있는 내용 자체를 의미합니다.
1. BDD 수행 과정
💡 BDD 수행 과정
1. 요구사항 명세화
- 비즈니스 요구사항이나 기능 요구사항을 이해하고 분석하여 사용자의 행동을 중심으로 한 '시나리오를 작성'합니다. 이 과정에서는 도메인 특정 언어를 사용하여 비개발자도 이해할 수 있는 방식으로 시나리오를 명세화합니다.
2. 테스트 케이스 작성
- 작성된 시나리오를 기반으로 테스트 케이스를 작성합니다. 이때 테스트 케이스는 사용자의 행동 중심으로 작성되어야 합니다.
3. 테스트 수행
- 작성된 테스트 케이스를 수행합니다. 이때 테스트는 실패하게 됩니다. 왜냐하면 테스트 케이스에 따른 기능이 아직 구현되지 않았기 때문입니다.
4. 코드 구현
- 테스트 케이스를 통과시킬 수 있는 최소한의 코드를 구현합니다.
5. 테스트 확인
- 구현된 코드가 테스트 케이스를 통과하는지 확인합니다. 통과하지 못할 경우 코드를 수정하여 테스트를 통과하도록 합니다.
6. 리팩토링
- 코드를 개선하여 가독성을 높이고, 중복을 제거하며, 코드의 품질을 향상합니다.
2. 테스트 시나리오 작성: Given, When, Then
💡 테스트 시나리오
- 개발자가 작성하는 시나리오로 원하는 기능이 어떻게 동작해야 하는지를 명세하는 것을 의미합니다.
- 테스트 케이스는 개별적인 테스트 단위로서, 특정 입력에 대한 기대된 출력을 확인하는 역할을 합니다.
💡 테스트 시나리오 작성: Given, When, Then
- ‘사용자의 행위’를 기반으로 ‘테스트 시나리오’를 구성하여 ‘테스트 케이스’를 구성하는 방법에 대해 알아봅니다.
- 즉 기획자가 작성한 ‘요구사항’이나 ‘기획서’에 적혀있는 내용들을 기반으로 테스트 시나리오를 구성하며 이를 기반으로 테스트 케이스를 구성합니다
💡 BDD 구조
- BDD에서는 Given, When, Then이라는 구조를 사용하여 요구사항과 기능에 대해 테스트 시나리오를 정의합니다
1. Given(=주어진 환경)
- ‘사용자 행위’를 수행하기 위해 주어진 ‘환경’에 대해 서술합니다.
- 해당 단계에서는 시스템이나 애플리케이션의 초기 상태, 환경, 입력 등에 대해 서술합니다.
ex) “사용자가 페이지에 접속해 있는 상황에서“
2. When(= 행위)
- 실제 사용자 행위에 대해서 서술합니다.
- 해당 단계에서는 시스템이나 애플리케이션 내에 발생하는 특정 조건이나 이벤트들에 대해 서술합니다.
ex) “사용자 아이디 필드에 ‘adjh54’을 입력하고 비밀번호 필드에 ‘12345’를 입력하고 ‘로그인’ 버튼을 누르면”
3. Then(= 기대결과)
- 행위에 따른 기대결과를 서술합니다.
- 해당 단계에서는 예상되는 동작이 실제로 발생하는지 확인하고 기대한 결과가 나오는지에 대한 검증을 수행하여 서술합니다.
ex) “로그인이 성공하고 메인 페이지로 이동한다”
💡 최종적으로 아래의 테스트 시나리오가 나오게 됩니다.
- “사용자가 페이지에 접속해 있는 상황에서(Given)”, “사용자 아이디 필드에 ‘adjh54’을 입력하고 비밀번호 필드에 ‘12345’를 입력하고 ‘로그인’ 버튼을 누르면(When)”, “로그인이 성공하고 메인 페이지로 이동한다(Then)”
3. TDD와 BDD의 상호보완적 관계
💡 TDD와 BDD의 가장 큰 차이점은 아래와 같습니다.
💡 TDD의 테스트 케이스
- ‘기능’을 확인하기 위한 목적으로 작성을 합니다.
ex) 계산기 기능을 만들었다고 가정하였을 때, add 함수의 파라미터로 1과 1이 들어갔을 경우 2의 값이 나오는지에 대해 확인합니다.
💡 BDD의 테스트 케이스
- 시나리오를 주체로 한 ‘행위’를 확인하기 위한 관점에서 작성을 합니다.
ex) 계산기 기능을 만들었다고 가정하였을 때, 사용자가 ‘1’ 버튼을 클릭하고 ‘+’ 버튼을 클릭하고 ‘1’ 버튼을 클릭했을 때 화면상에 ‘2’가 표시가 되는지를 확인합니다.
💡 위에서 언급했듯이 BDD는 TDD에 파생된 개념 중 하나입니다. 그렇기에 선택이 아닌 서로 간은 상호 보완적인 관계입니다.
💡 TDD의 관점
- TDD에서 보기 어려운 ‘유저 시나리오’ 관점을 확인할 수 있습니다.
💡 BDD의 관점
- BDD에서 보기 어려운 TDD 테스트 케이스를 통해 모듈들을 테스트 커버리지를 극복이 가능합니다.
💡 아래는 TDD와 BDD의 동작 사이클입니다.
- BDD가 수행되기 위해서는 TDD 사이클이 함께 더해지는 구조로 이루어집니다.
- BDD의 사이클이 통과해야 하고 TDD도 함께 통과를 해야 하나의 테스트 구조가 완료가 됩니다.
4. TDD와 BDD를 적용할 때의 가장 큰 장점
💡 TDD와 BDD를 적용할 때의 가장 큰 장점
- 아래와 같이 기획 → 설계 → 코드 작성의 과정을 거치며 구성을 하는 도중에 큰 변화가 필요한 문제가 발생하는 ‘기회 누락 발견’이 발생할 수 있습니다.
- 기획이나 설계단계에서 누락된 기능이 발생하여 코드 개발을 변경하는 과정이 발생합니다
💡 그렇기에 아래와 같이 TDD에서는 기획 - 설계 단계에 ‘테스트 케이스’를 작성하여 사전에 ‘예외 케이스’를 찾아서 발견하여 추후에 발생하는 문제에 대해 줄일 수 있습니다. 시나리오 작성 시 사전에 이슈를 발견할 수 있습니다.
4) TDD, BDD 최종 정리
💡 TDD, BDD 최종 정리
- TDD와 BDD는 목적에 따라서 사용여부를 결정해야 합니다. 또한 각각의 장단점에 대해 알고 개발방법론으로 적합한지에 대해 판단하여 사용하여야 합니다.
| 분류 | TDD (테스트 주도 개발) | BDD (행동 주도 개발) |
| 정의 | 테스트가 개발의 중심이 되는 개발 방식. 먼저 테스트를 작성하고 그 테스트를 통과하는 코드를 작성함으로써 소프트웨어의 품질을 높이는 방법론 | 행동을 기반으로 테스트를 작성하는 방법론. 사용자의 행동이나 시스템의 반응을 기반으로 테스트를 작성함으로써 소프트웨어의 품질을 높이고 사용자 중심의 개발을 가능하게 함 |
| 목적 | 기능 동작의 검증, 코드의 품질 향상 | 서비스 유저 시나리오 동작의 검증, 사용자 중심의 개발 |
| 설계 중심 | 제공할 모듈의 기능 중심 설계 | 서비스 사용자 행위 중심 설계 |
| 테스트 코드 설계 주체 | 모듈 사양 문서(개발자가 작성) | 서비스 기획서(서비스 기획자가 작성) |
| 적합한 프로젝트 | 모듈/라이브러리 프로젝트 | 서비스 프로젝트 |
| 장점 | 코드의 결함을 미리 찾아내고, 코드의 품질을 보장. 코드의 리팩토링과 유지보수가 쉬움 | 사용자의 관점에서 테스트를 작성하여 사용자 중심의 개발을 가능하게 함 |
| 단점 | 테스트 작성에 시간이 많이 소요될 수 있음 | 사용자 행동에 대한 정확한 이해가 필요함 |
오늘도 감사합니다. 😀
반응형
'공통 > 개발방법론' 카테고리의 다른 글
| [개발방법론] 스크럼(Scrum) 방법론 이해하기 (0) | 2023.03.14 |
|---|---|
| [개발방법론] 애자일 방법론과 종류: 칸반, 스크럼, 익스트림 프로그래밍 (0) | 2023.03.11 |
| [개발방법론] 소프트웨어 개발 방법론 : 폭포수(Waterfall), 애자일(Agile), 린(Lean) 방법론 (0) | 2023.03.11 |
