TDD 무엇을 테스트 할 것인가?

Decription

As Sam

I want to login into system.

So I can see my own content and so I can receive credit for any transactions I complete

Given a specified user Sam,

When Sam inputs a valid user ID and password

Sam can log in and begin scanning/searching for products to add to cart,

1. 스토리의 첫번째 부분

  - As/want/So

  - 이 스토리를 통해서 사용자가 어떤 가치를 얻을 수 있는지 기술

2. 스토리의 두번째 부분

  - Given/When/Then

  - Acceptance criteria : Product Manager가 이 스토리의 완료여부를 판단할 기준

※ 비교

ATDD : Acceptance Test Driven Development

BDD : Behavior Driven Development

"제대로된 TDD를 하기 위하서는 테스트케이스는..."

① 지금까지 처리한 스토리들을 온전히 기술

  - 수동으로 다시 앱을 실행하지 않고도 지금까지 구현된 기능들이 망가지지않고 잘 실행됨을 확신

② 구현의 변경에 강해야함

  - 단위테스트가 구현에 밀접하게 연관되어 조밀하게 작성돼있다면, 리팩토링 시도시 관련 모든 테스트코드를 수정해야함

  - 높은 레벨에서 테스트케이스를 작성하면 세부적인 구현 변경시 테스트코드 변경노력을 줄임

위 두가지 장점은 개발의 효율성으로 이어짐

[TDD Cycle]

가장 단순한 코드를 작성해야함

지금 작성하고 있는 스토리에 집중

예) 스토리 : "사용자는 적용할 수 있는 할인의 종류를 볼 수 있다" 라고 하면

- 할인의 종류를 보여주는 것으로 충분함

- 할인의 종류를 하드코딩해서 보여주는 것이 가장 훌륭한 구현

- 이후, 할인의 종류가 변경된다면 역시 또다른 스토리로 작성되고

- 해당 스토리 처리시 할인의 종류를 DB에서 관리할지, 하드코딩된 값을 바꾸는 것으로 충분할지 Product Manager와

  논의를 진행해도 충분함

이런 방식의 가장 큰 장점은 빠른 개발

TDD로 개발하면 개발속도가 느릴것 이라는 오해와 달리 이런원칙을 지킨다면 정말 빠른 속도로 개발할 수 있음

"개발자의 가정에 의해 일하지 않는다"

할인의 종류가 변경될 것이다라는 것은 PM에게 확인받기전까지는 개발자의 가정일뿐.

만반의 준비를 갖춰놓아도 Price Error / Price Match 두가지 할인만을 지원하면 되는 시스템이라면 그간의 노력은

리소스를 낭비한 것 일 수 밖에 없음

PM의 대답은 대개 "지금은 괜찮다. 이후에 할인종류 변경관련 스토리가 추가될 것이다" 일 가능성이 높음

가정에 일하지 않는다는 원칙은 모든 부분에 적용됨

가정을 없애기 위해 개발자들은 PM, UX디자이너와 끊임없이 이야기해야함.

https://monkeyisland.pl/2009/12/07/given-when-then-forever/

//given //when //then forever

@Test
public void shouldDoSomethingCool() throws Exception {
    //given
      
    //when
  
    //then
 
}

[참고]

BDD 툴 : Mockito

Cucumber