객체지향적인 코드개발 가능 : "모든 코드"가 재사용 성 기반으로 작성되어야 하기 때문에 보다 기본적으로 객체지향적인 코드가 되는 것입니다.
설계 수정시간의 단축
리팩토링의 유연함, 변경사항이 생겨도 자신감.
단점
비용증가. 귀찮음
굳이 이거까지해야되나? 싶음
의존성이 있는 부분에 대한 테스트는 역시나 어려웠습니다. 가장 큰게 디비였는데 Mock을 연결해야 더 깔끔한 테스트를 할 수 있는데 테스트도 익숙치 않은데 Mock에 대한 부분까지 익혀서 하는 것은 시간상으로도 여유가 없었기 때문에 그냥 테스트후 트랜잭션 롤백을 하는 것으로 해서 디비를 직접 물고 테스트를 작성하였습니다.
픽스쳐는 테스트를 위한 기본적 데이터인데 연습할때는 괜찮았지만 실제 업무에서 사용하다 보니 엄청나게 다양한 픽스쳐가 필요했습니다. 일반적으로 픽스쳐는 @Before에서 처리를 하는데 테스트를 만들다 보니 전체적으로 공통인 픽스쳐가 그리 많이 존재하지 않았고(제가 그렇게 구조화 하기가 어려운 것일수도) 결국 거의 모든 테스트 케이스마다 픽스처를 잡아주면서 테스트를 작성해야 했습니다.일부 공통적인 부분은 따로 메서드로 추출했지만 @Before는 시간이 지나면서 픽스처설정 용으로는 거의 쓰지 않게 되었고 픽스쳐 설정으로 인해서 테스트는 길어지고 복잡해 졌습니다.
Feature : 테스트에 대상의 기능/책임을 명시한다.
Scenario : 테스트 목적에 대한 상황을 설명한다.
Given : 시나리오 진행에 필요한 값을 설정한다.
When : 시나리오를 진행하는데 필요한 조건을 명시한다.
Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.
TDD 는 기능중심이라면, BDD는 행동중심이다. 즉, 돌아가기만하게 하려면 TDD, 모든 요구사항 구현을 테스트하려면 BDD로..!
TDD vs BDD
TDD : Test-driven Development
장점
단점
참고
BDD : Behavior Driven Development
TDD 는 기능중심이라면, BDD는 행동중심이다. 즉, 돌아가기만하게 하려면 TDD, 모든 요구사항 구현을 테스트하려면 BDD로..!
결국 둘다 사용해서 코딩을 해야하는게 좋음..
https://cucumber.io/