서론
요즘 TDD, BDD와 같은 방법론에 대해 여러 의견들이 있는 것을 보았다.
그 내용들과 무관하게 TDD를 공부하며 적용하고, 적절한 부분에서 사용하게 된 배경을 공유하고, 피드백을 받음으로, 다른 의견들을 보고 배우고싶어서 부족한 지식이지만 짧은 생각을 글로 남겨본다.
TDD
TDD라는 용어를 약 5년전에 용어를 처음 접했다.
그때 보이던 글들에 의해서는 red-green-blue와 같은 사이클을 가지는 개발 프로세스이고, 되게 좋아보였다.
정리해보면 결국은 테스트코드를 먼저 작성하고, 테스트코드를 성공하기 위한 로직을 작성한 후 리팩토링하는 프로세스이다.
TDD적용 사례 1
TDD를 한 번에 모든 업무에 도입하지는 않고, 일부 작업들에 활용했다.
첫 사례로는, 이미 만들어진 시스템에 버그가 발생했고, 이를 해결하는 과정에 적용해본 것이다.
그러면,
1. 문제가 되었던 파라매터들을 준비해서 regression test를 작성한다.
2. 의도된대로 실패하는지 확인한다.
3. 해결 후 동작이 잘 되는지 확인한다.
4. 1~3을 반복 이후 로컬 혹은 개발서버에서 실제 유저의 시나리오를 재현하며 동작이 잘 되는지 확인한다.
순서로 개발이 끝나게 된다.
이 과정에서는 4번을 가장 마지막에 할 수 있게되어 데이터 세팅, 브라우저 새로고침 등 번거로운 작업을 뒤로 미루게되어 효율적이었다.
즉, 테스트 실행을 IDE에서 간편히 할 수 있는 세팅과의 시너지가 있었다.
TDD적용 사례 2
하지만, 신규 기능을 새로운 구조로 구현할 때는 비효율의 어려움이 있었다.
테스트를 작성하며 새로운 모델, 코드 구조를 작성한다.
=> 작성 중인 코드 혹은 구상중인 코드가 비효율적이라고 판단되는 피드백이 느리다.
머릿속으로 코드 구조를 상상하고, 비효율적이라고 판단되면 다른 구조를 생각하는게 훨씬 빠르고 효율적이다.
=> TDD를 활용하면 무의식적으로 코드 작성에 집중하게 되어, 구조 개선에 집중이 안된다.
라는 결론이 나왔다.
TDD적용 사례 3
리팩토링에서도 TDD의 방법을 따와서 작업하면 효과적이다.
이미 기존 로직들에 테스트 코드가 있다면, 동작이 깨지지 않는 선에서 수정하기가 수월하다.
하지만, 테스트 케이스 및 테스트 코드가 없는 경우는 기존 동작이 유지된다는 100%확신을 할 수 없다.
따라서 테스트 코드를 만들어서 기존 동작을 보장시키고, 내부 구현 최적화를 하는데에는 자신감있게 작업할 수 있어서 좋았다.
결론
TDD방법론은 이상적인 시나리오를 위해 나왔다고 생각한다.
하지만 현실의 문제는 '시간 = 비용'이다.
따라서 적절히 TDD의 방법론의 방법을 엔지니어링에 적용하니,
1. 작업의 자신감
2. 작업의 속도
가 장점으로 작용되는 부분이
- regression test
- refactoring
에 있었다.
다른 부분들은 딱히 드라마틱한 이점이 없었다.
