TDD(Test-Driven Development) 도입에 관한 고려 사항

[ms1011]

TDD란?

소프트웨어 개발 방법론 중 하나로, 간단히 말해 "테스트 주도 개발"이라고 할 수 있습니다.
이 방법론은 소프트웨어 개발 과정에서 테스트 케이스를 먼저 작성한 후에 해당 테스트 케이스를 통과할 수 있는 코드를 작성하는 방법을 말합니다.

TDD 싸이클

TDD는 Red→ Green→ Refactor총 3단계의 구성으로 되어있고, 이러한 3단계를 반복하면서 코드를 점진적으로 개발하고 개선할 수 있습니다.

1. Red: 실패하는 테스트 케이스를 작성

   • 아직 구현되지 않은 기능 또는 수정해야 할 버그 등을 나타내는 테스트입니다. 테스트 케이스가 실패하는 것이 예상되므로 "빨간색"이라고 합니다. 핵심은 실패하는 테스트 코드를 작성하는 것입니다.

   @Test
   void plusTest() {
       // given
       Calculator calculator = new Calculator();  // Calculator 클래스가 없어 테스트 실패!
   
       // when
       int result = calculator.plus(1, 3);  // plus 메소드가 없어 테스트 실패!
   
       // then
       assertThat(result).isEqualTo(4);
   }

   위 테스트 코드는 실패하는 코드입니다. Calculator 클래스를 아직 작성하지 않았기 때문입니다.

2. Green: 테스트 케이스를 통과할 수 있는 최소한의 코드를 작성

   • 위에 작성한 실패하는 테스트 코드를 최대한 간단하고 빠르게 테스트 케이스를 통과시키기 위해 작성합니다. 목표는 최대한 빠르게 테스트를 통과하는 것입니다. Green 단계에서는 테스트 코드를 통과하기 위해서는 코드의 완성도를 생각하지 않는 것이 핵심입니다.

   public class Calculator {
       public int plus(int a, int b) {
           return 4;  // 일단 테스트를 통과하게 하기 위하여 변수가 아닌 상수를 반환
       }
   }

   Calculator 클래스를 구현할 때 최대한 빠르게 Green 단계에 도달하기 위해 변수가 아닌 상수를 반환하는 코드를 작성하고 점진적으로 변수로 바꾸어 나가는 것도 가능합니다. 위의 코드는 실제로 덧셈을 수행하지는 않지만, 테스트를 통과하기 위해 상수를 반환하는 코드를 작성하였습니다.

3. Refactor: 작성된 코드를 리팩터링

   • 구조를 개선하고 중복을 제거합니다. 이 단계에서는 테스트가 성공하고, 코드의 기능이 변경되지 않아야 합니다. 목표는 코드의 가독성, 유지 보수성, 확장성 등을 개선하는 것입니다.

   public class Calculator {
       public int plus(int a, int b) {
           return a + b;  // 정상적으로 동작하게 코드 수정하기
       }
   }

   위 코드는 테스트만 통과하기 위해 작성된 코드를 리팩터링 한 코드입니다. 이 단계에서는 Green단계에서 통과만을 위해 작성된 코드를 수습합니다.

TDD의 원칙

1. 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드(실제 사용자가 실행하는 소스 코드)를 작성하지 않습니다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성합니다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성합니다.

TDD의 장점

한번에 하나의 일만 집중할 수 있다

TDD 를 적용하지 않은 상황에서는 코드를 작성합니다, 다른 코드에 한눈이 팔리고, 다른 모듈을 건드리게 되다 보면 '내가 뭘 하고 있었더라?' 라는 생각이 들기 쉽습니다. TDD를 적용하면, 프로덕션 코드를 작성하며 현재 실패한 테스트 케이스를 통과하는 데에만 집중할 수 있습니다. 야크털 깎기 (Yak Shaving) 를 하지 않을 수 있습니다.

야크털 깎기란?
원래 목적이 무엇인지 잃어 버리고 엉뚱한 일을 하면서 엄청난 시간을 까 먹는것

• 봄이 왔으니 세차를 해야 겠네.
• 이런 호스가 겨우내 터졌네. 홈 디포우에서 새거를 하나 사야겠군.
• 홈 디포우는 Tappan Zee 다리를 건너야 하고 그러려면 EzPass(하이 패스 같은 건가 봅니다.) 가 있어야 하는데.
• 음 옆 집 Bob 한테 EZPass 를 빌려야 겠군.
• 그런데 아들 넘이 옆 집 Bob한테서 보이스카웃에 가려고 베개를 빌려갔었는데.....
• Bob은 빌려간 베개를 돌려주기 전까지는 그의 EZPass 를 빌려주지 않을 거야...
• 음 그런데 베개에 있는 야크 털이 많이 빠져서 지금 당장 돌려줄수가 없겠네..
• 베개에 넣을 야크 털을 구해서 베개를 고쳐야 겠네..
• 그래서 세차를 하기 위해 동물원에 가서 야크 털을 깍는중…

디버깅 시간의 단축

통합 테스팅이 아닌 유닛 테스팅을 하는 이점이기도 합니다. 우리는 각각의 모듈 별로 테스트를 자동화 할 수 있는 코드가 없다면 특정 버그를 찾기 위해서 모든 레벨의 코드들을 살펴봐야 합니다. 예를 들어 사용자의 데이터가 잘못 나온다면 DB의 문제인지, UI단의 문제인지 실제 모든 레이어들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있습니다.

테스트 코드 자체가 문서가 될 수 있다

TDD 를 적용하며 작성한 테스트 코드는 다른 관점에서 보면 '프로덕션 코드에 대한 요구사항' 입니다. 이는 테스트 코드 자체가 문서가 될 수 있음을 알려줍니다.

테스트를 나중에 작성하는 것은 귀찮다

프로덕션 코드를 작성한 상태에서 테스트 케이스를 작성하는 것은 귀찮습니다. 따라서 프로덕션 코드를 작성한 다음 테스트 케이스를 작성하게 되면, 프로덕션 코드에 맞춰 통과하는 테스트 케이스를 만들게 될 수 있습니다. 이렇게 되면 테스트 코드의 의미가 무색해질수도 있습니다.

재설계 시간의 단축

TDD는 테스트 코드를 먼저 작성하기 때문에 내가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 됩니다. 또한 테스트 시나리오를 작성하면서 다양한 예외상황에 대해 생각해 볼 수 있으며 이는 완성도 높은 설계로 이어집니다. 따라서 매우 크리티컬한 예외상황이 생길 확률이 극히 낮으며, 개발진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있습니다.

추가 구현의 용이함

개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드들에 어떤 영향을 미칠지 모른다는 점입니다. 따라서 단순한 기능이라도 추가 된 후에는 모든 기능들을 처음부터 테스트 해야합니다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전재하므로 이러한 테스트 기간 역시 획기적으로 단축 시킬 수 있습니다.

TDD의 단점

생산성의 저하

개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 합니다. 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문입니다.TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어납니다.

의견

생산성의 저하라는 단점이 치명적으로 다가올 수 있습니다. 기한이 짧게 선정된 프로젝트의 경우에서는 TDD를 적용하는 것이 큰 단점이 될 수 있습니다. 반면에 기한이 짧지 않은 경우에는 TDD의 도입하여 완성도 높은 코드를 작성하는 것이 좋을 것 같습니다. 저희 프로젝트의 경우 후자에 가깝다고 생각되어 TDD를 도입하여 완성도 높은 코드를 구현하려고 노력하는 것이 더욱 좋은 방향인 것 같습니다. 다른 팀원분들의 의견도 궁금합니다.

[orlzlL]

저는 찬성합니다. 테스트 코드를 작성하는 번거로움을 감수하더라도 테스트 케이스에 맞추어 개발하면 안정성을 확보할 수 있을 것 같습니다! 또한 추후 CI/CD를 활용한 자동화 테스팅에도 활용할 수 있을 것으로 생각됩니다.