이전에 페스트캠퍼스를 통하여 구매하였던 테스트 주도 개발(TDD, Test Driven Development) 강의를 최근 다시 보고있다. 오늘은 공부하면서 내가 이해한 테스트 주도 개발에 대하여 정리를 해보려 한다. 해당 포스팅에 대해 틀린점이나 다른 의견이 있을 경우 언제든지 댓글을 남겨주면 좋을 것 같다.
TDD에 대한 뚜렷한 이해 없이 사내 혹은 사이드 프로젝트 및 개발 공부를 하며 단위 테스트 코드를 같이 작성하며 개발을 해오고 있었다. 처음엔 개발자들 사이에서 자주 거론되기 시작하고 점점 더 중요해지는 추세가 되다보니 꼭 해야할것 같아서 막연하게 사용하기 시작했는데 막상 하다보니 코드 안정성을 향상 시키고 각 단위별 변경점 발생 시 테스트를 돌려봄으로써 바로 이번 변경이 변경한 부분 이외에도 이 부분을 참조해서 사용하고 있는 다른 메서드들 까지 이상이 없는지 간단하게 테스트하고 피드백을 받을 수 있다보니 추후 변경점이 큰 리펙토링을 하게 될 경우에도 버그 발생에 대한 부담감이 줄어들었다.
그러다가 테스트 주도 개발에 대해 공부하게 되면서 단순히 포스팅 글을 보는것만으로는 이해가 되지 않았던 Red, Green, Refactor Cycle에 대해서 조금 더 이해할 수 있었다. 그래서 Red, Green, Refactor Cycle에 대한 프로세스를 조금 더 명확히 정리 해보려 한다.
위 그림은 다들 너무 많이봐서 잘 알고 있을것이다. Red는 테스트 실패, Green은 테스트 성공, Refactor는 테스트를 단순히 성공 시키면서 작성한 코드를 간결하게, 혹은 구조화 하는 단계이다. 여기서 처음에 가장 이해가 가지 않았던 부분은 Red 단계였다. 왜 실패하는 단계가 있어야 하는지? 그 이유는 테스트가 전체 개발을 주도하여 개발을 이끌어 나가야 하기 때문이다.
# 기존의 개발 흐름
요구사항 이해 -> 프로덕트의 흐름 구체화 -> 역할 단위로 필요한 인터페이스 정의 -> 로직 구현
# 테스트 주도에 따른 개발 흐름
요구사항 이해 -> 프로덕트의 흐름 구체화 -> 인터페이스 정의 -> 역할 단위로 필요한 인터페이스 정의 -> 프로덕트의 흐름 단위로 테스트 해야 할 테스트 작성 -> 테스트 실패(Red) -> 테스트가 성공 하도록 로직 구현(Green) -> 로직을 간결화 해야 할 코드나 전체적으로 구조화 시킬 수 있는 부분들이 있을 경우 리펙토링 하고 없으면 다음 단계 진행(Refactor)
위의 두 케이스에서 #기존의 개발 흐름 의 경우 로직 구현 에 해당하는 부분이 #테스트 주도에 따른 개발 흐름 에서는 수많은 단계로 나뉜다. 이 이유는 테스트 주도 개발이란 프로덕트의 흐름을 각 테스트 케이스별로 그 흐름을 따라가면서 구현하는 방식이기 때문이다. 그렇기 때문에 각 로직에 변경점이 생겨도 프로덕트의 흐름대로 단위별 테스트 케이스를 돌려 보면서 변경한 코드에 대한 전체 피드백을 받을 수 있다.
물론 프로덕트의 흐름대로 단위 테스트들이 작성되었고 모두 통과했다고 하더라도 완벽하다고 보장할 순 없으며 인수 테스트는 반드시 진행 되어야 한다. 그럼에도 테스트 주도 개발을 선호하는 이유는 그냥 개발을 하였을 때보다 더 코드품질을 보장받을 수 있고 개발 도중 혹은 추후 로직에 변경점이 생길 경우에도 바로바로 테스트 코드를 돌려 정상적으로 동작하는지 피드백을 받아볼 수 있기 때문이다.
Part 2 에서는 테스트 주도 개발(TDD, Test Driven Development) 프로세스를 조금 더 넓은 시야에서 다뤄보도록 하겠다.
