TDD와 BDD

TDD

일반적인 개발 과정

디자인 → 코드 작성 → 테스트
    ←----------------
        설계 수정

• 정확한 프로그래밍 목적을 디자인 단계에서 반드시 미리 정의해야한다.
• RED: 실패하는 테스트 만들기
• GREEN: 테스트에 통과할 만한 작은 코드를 작성하기
• REFACTOR: 반복되는 코드, 긴 메소드, 큰 클래스, 긴 매게변수 목록 등등 코드를 좀 더 효율적으로 바꾼다.

• TDD를 하면 좋은 경우
  • 처음해보는 프로그램 주제
    • 나에 대한 불확실성이 높을 경우
  • 고객의 요구조건이 바뀔 수 있는 프로젝트
    • 외부적인 불확실성이 높은 경우
  • 개발하는 중에 코드를 많이 바꿔야 된다고 생각하는 경우
  • 내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
  • 즉, 불확실성이 높을 때 TDD를 하면 된다.
• TDD를 하면 ‘Test’는 명사가 된다. 명사가 되기에 ‘Test’(대상, 목적어)를 남에게 공유하기가 쉬워진다. 공유함으로 협력이 증진될 수 있다.
• 즉, TDD의 정의와 같이 테스트 코드를 보면 그 사람의 의사결정이 나타나고 상대방은 그 부분은 왜 그렇게 짰는지를 쉽고 빨리 알게 되기 때문에 협력이 증진된다.

TDD 잘 활용하기

• TDD에 반드시 툴 단위 프레임워크를 사용해서 이렇게 해야한다. 라고 생각하면서 테스트 코드를 작성하는 것은 바람직하지 못함. 이러한 규칙에 얽매이는 것은 애자일이 아니다.
• 항상 스스로 ‘어떻게 해야 피드백을 더 자주 받을까', ‘어떻게 해야 내가 하는 작업에 대해 협력이 잘 일어나게 할까'를 고민하면서 계속해서 내가 일하는 방식을 업그레이드 해야 한다.

BDD

• story 파일의 유무가 TDD와 BDD의 차이점을 말해준다.
  • story 파일은 비 개발자와 소통을 돕고 앱의 행동을 규정하는 것.
  • BDD 프레임워크들은 story 작성을 기술적으로 도와준다.

Story File

• story 파일은 크게 User Story와 Scenario로 구성된다.
  • User Story는 이 프로젝트에서 무엇이 개발되어야 하는지에 관한 내용.
  • Scenario는 그에 따른 구체적인 예시

User Story

As a <Stakeholder>

I want <Capability>

So that <Value>

• User Story는 보통 이 형태를 따른다.

메신져 앱으로 이것을 살펴보면, 메신져 앱의 User Story는 사용자로서 나는, 친구들의 목록을 확인할 수 있고, 따라서, 친구의 이름을 확인할 수 있다. 이런 형태를 통해서 “누가", “무엇을", “왜"에 대한 대답을 명확히 할 수 있는 것.

Scenario

Given <Precondition>

When <Action>

Then <Output>

• Scenario는 다음과 같은 형태를 따른다.

하나의 User Story에 여러개의 Scenario를 가질 수 있다. User Stroy와 Scenario 작성에는 기술적 용어를 피해 누구나 이해할 수 있게 해야한다. Scenario가 작성되면 이를 구현하기 위한 Test 작성을 시작한다.

규칙에 얽매이지 말고 어떻게 하면 피드백을 더 잘받을지, 협력이 잘 될지 고민하면서 발전해야 TDD에 효과가 생긴다.

 

결론

BDD에서는 테스트 코드를 미리 작성하는 것이 목적이 아닌 “행동"을 정의하는 것이 먼저여야 한다.

1. Scenario를 먼저 작성 후,
2. ViewModel의 input, output과 사용할 Model을 정의하고
3. 테스트 코드를 작성

하는 것이 바람직해 보임.

 

참고자료

[Agile] TDD(테스트 주도 개발)란 - Heee's Development Blog

 

TDD(Test Driven Development) 와 BDD(Behavior Driven Development)