테스트 주도 개발(Test-driven development TDD)는 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 테스트 코드와 프로덕트 코드를 독립적이지 않고 함께 진행하는 것이다.
과정
- 코드의 몇 줄 또는 작은 단위의 구현할 기능을 선택한다.
- 이 기능에 대한 테스트 코드를 작성한다.
- 작성된 테스트들을 실행한다. 처음에는 기능을 구현하지 않으므로 fail이 된다.
- 프로덕트 코드를 작성하고 테스트를 재실행한다.
- 모든 테스트가 성공하면 다음 기능 구현으로 이동한다.
TDD의 장점
- 코드 커버리지가 높아진다. 작성된 프로덕트 코드들은 최소 하나이상의 테스트와 연관이 있기 때문에 모든 코드에 대한 테스트가 가능해진다.
- 코드를 수정했을 때, 바뀐 코드가 기존 동작에 문제를 발생시키지 않는지 쉽게 확인할 수 있다.
- 테스트가 실패했을 때, 문제가 어디서 발생하는지 쉽게 알 수 있다. 관련된 코드만 확인하면 된다. 이 부분은 TDD의 장점 보다는 유닛 테스트의 장점에 가깝다.
- 테스트 코드 자체가 코드가 무엇을 하는지 보여주는 문서의 역할을 할 수 있다.
TDD와 리팩토링
프로덕트 코드를 리팩토링 할 때 클래스의 생성자 또는 메소드의 시그니처가 수정되는 경우에 테스트 코드를 포함한 많은 부분에서 수정해야되는 문제가 발생한다. 이렇게 시그니처를 바로 바꿔서 컴파일 불가능한 코드로 바꿔서 리팩토링하는 것은 좋지않다.
이런 경우 기존의 메소드 또는 생성자를 지우거나 수정하지 않고 완전히 새로 하나 만든 후, 기존 메소드에 대한 호출을 하나씩 지우고 최종적으로 기존의 코드를 지우는 방법이 좋다.
// 리팩토링이 완료되면 이 메소드는 지워진다.
public int match(List<Integer> userLotto, List<Integer> winningLotto) {
}
// 리팩토링 할 대상의 코드를 바로 지우지 않고 새로운 메소드를 만든다.
public int match(List<LottoNumber> userLotto, List<LottoNumber> winningLotto) {
}
이렇게하면 새로운 메소드에서 문제점을 발견하여 다시 복구 시킬 수 있고(쉽게 말해 백업이 가능하다), 기존의 코드 메소드에서 호출을 하나씩 수정하면서 점진적으로 리팩토링이 가능해진다. 컴파일이 불가능해지면 점진적인 테스트가 불가능하다!
댓글남기기