TDD
TDD
Test Driven Development. 테스트 주도 개발은 개발을 한 후에 그에 대한 테스트 케이스를 통해 개발이 잘 이루어졌는지 테스트하는 기존의 개발 방법론들과는 다르게 테스트 케이스를 먼저 작성하고 해당 케이스를 토대로 개발을 하는 개발 프로세스이다.
개발 프로세스 비교
기존의 개발 프로세스
[ [ 설계 - 개발 - 테스트 ] - 설계 수정 ]
TDD 개발 프로세스
[ [ 설계 - 테스트 ] - 설계 수정 ] - 개발 ]
테스트 주도 개발 프로세스의 장 / 단점
장점
-
코드의 유지보수가 용이하다
일반적인 경우의 개발에서는 버그를 수정하거나 기능을 추가하거나 하는 등의 작업에서 비용이 많이 들게 된다. 하지만 테스트를 작성하게 되면 코드들이 테스트를 거쳐 개발되었기 때문에 각 코드들의 동작이 보증이 된다. 그렇기에 현재 개발하는 부분에만 신경을 쓸 수 있다.
-
프로그래밍을 하는 시간이 단축된다
프로그래밍을 할 때, 문제를 해결하는 디버깅에 시간이 많이 쓰인다. 보통의 개발 방법에서는 코드를 다 작성한 후에 디버깅을 하기 때문에 특히 디버깅에 걸리는 시간이 길다. 하지만 테스트 주도 개발의 경우에는 단위별로 테스트 / 디버깅을 하기에 디버깅을 하는 시간이 짧아, 결과적으로 프로그래밍에 들이는 시간이 단축된다.
-
프로그램의 소스코드 기록이 뛰어나다
프로그램의 소스코드를 작성하며 주석을 통해 그에 대한 기록을 통해 왜 이렇게 코드를 짰는지에 대해 작성하게 된다. 테스트 주도 개발의 경우, 단위 테스트를 통해 각 단위별 코드의 동작을 볼 수 있기에 주석을 통해 각 유닛의 동작에 대해 기록할 수 있다. 이를 통해 프로그램의 수정과 확장의 용이성을 보장할 수 있다.
단점
-
실수를 미리 알아차리는 것이 쉽지 않다
테스트를 미리 작성한다는 것은 우리가 어떤 실수가 나올 것이라고 가정할 수 있을 때의 상황에서 가능한 것이다. 우리가 실수를 미리 알고 테스트를 작성한다면 이상적인 시간 단축을 경험할 수 있지만, 거의 모든 상황에서 우리가 실수를 미리 인지한다는 것은 불가능에 가깝다. 그렇기에 이 방법을 통해 시간을 단축한다는 것은 이상에 가깝다고 볼 수 있다.
-
테스트가 통과했기에 문제가 없다고 생각할 수 있다
테스트가 모든 상황을 해결해주지는 않는다. 단순히 개발 과정에서 테스트를 통과했다고 해서 고객의 요구사항을 충족시켜준다던가 하지 않기 때문에, 테스트가 통과했다고 해서 안심해서는 안된다. 1번 단점에서 볼 수 있듯이 테스트 단계에서 실수를 전부 알아차리기란 불가능에 가깝다. 그렇기에 우리가 인지하지 못한 문제가 발생할 수 있다. 테스트는 우리가 구현한 프로그램의 소스코드가 완벽히 동작하는 것을 확인하는 것이 아니라, 적어도 테스트가 된 구간에서만큼은 문제없이 동작한다는 것을 보여주기 위함이다. 이를 위한 것이 TDD 프로세스이다.
-
확장과 수정 등이 이루어지면서 기록이 계속해서 추가된다
우리가 테스트를 통해 한 구간에서의 동작이 잘 이루어지는 걸 확인하고 주석을 단다. 이 과정이 완벽하게 이루어지는 것은 테스트를 한 후에 이 구간에 대해 확장, 수정이 더 이상 이루어지지 않을 때의 얘기이다. 확장과 수정을 통해 이 구간에 변화가 일어난다면 우리가 주석을 작성한 대로 동작이 행해지지 않을 수 있다. 그렇기에 계속해서 주석과 같은 기록이 증가하게 된다.