MVVM이니 DI니 하는 것들에 말을 들어보면 항상 나오는말이 테스트가 용이하다는 말이었다.
그렇게 자연스레 Unit Test에 대한 공부를 하고 시작했고, 주로 외국인 유투브를 찾아보며 공부했는데, TDD에 대한 언급이 정말 많았다.
기왕 테스트 코드를 작성할거, 그렇게 TDD로 해보자는 생각이 들었다. 실패 해도 되고 아니면, 다시 고쳐서 하면 되니까, TDD를 시도해보는 도전을 해보기로 했다.

이 글의 내용은 내가 시작하기에 앞서 구글링한 내용을 거의 옮겨적은바나 마찬가지다...
차후 많은 것이 바뀔 것이라고 믿는다.

1. TDD, 뭘까?

TDD는 Test Driven Development으로 기존 개발 사이클, 디자인 - 구현 - 테스트 가 아닌 테스트가 먼저 진행되는 개발 사이클을 가진다.

• TDD는 다음과 같은 총 세가지 단계로 이루어 지는데
  

1. RED - 테스트가 실패함
2. GREEN - 테스트가 성공하기 위해 코드를 작성
3. Refactor - 중복 제거 등 리펙터링

• 이를 자세히 표현하면 다음과 같다.
  

• 핵심 개념
  켄트백에 의하면 TDD란 다음과 같다.

  a. 결정과 피드백 사이의 갭에 대한 인식
  b. 결정과 피드백 사이의 갭을 조절하기 위한 테크닉

  이 둘의 갭이 커지고, 그 갭이 무엇인지 모른다면 문제가 발생한다고 한다.
  즉, 둘 사이의 갭을 인식한다면, TDD를 하고 있다고 볼 수있다고 한다.

결정(decision) - 프로그램을 하는 방법에 대한 결정
피드백(feedback) - 프로그램의 성공/실패를 피드백

2. 어떻게 할까?

테스트는 다음과 같은 피라미드 구조를 가진다.

이런 테스트에서 중요하게 생각해야하는 속성이 있는데,
1. Scope - 내 어플리케이션에서 얼마나 많은 부분에 테스트코드가 작성되었는가. 이는 다음에 나오는 두 속성에 영향을 끼친다.(Scope가 커질수록 Speed는 느려지고, Findelity는 증가)
2. Speed - 얼마나 빨리 테스트 코드가 동작하는가?
3. Fidelity - 실제로 어플리케이션이 동작했을때와 얼마나 유사하게 동작하는가?
다.

그리고 테스트의 종류는
1. samll test - class, method 등 가장 작윈 단위 테스트(unit test)
2. medium test - 각 모듈간의 상호작용을 테스트(integration test)
3. large test - 유저가 앱을 사용하면서 겪는 상황을 가지고 하는 테스트(E2E test,UI test)
이렇게 구분한다.

이것들에 의거한 내가 생각하는 프로젝트 진행 방식은
먼저 각
1.small test- viewmodel, repository, dao 등의 테스트 코드 작성 후 실제 코드 작성 후,
2. medium test- 실제 구현된 viewmodel 등의 테스트,
3. large test- 아직 방법을 잘 모름...
의 방식으로 진행하려고 한다.

3. 앞으로 하고자 하는 바,

TDD는 사실 개념조차 명확하게 이해가지 않는다.

어렵다.

물론 하고자 하는 바는 TDD의 장점을 취하여 개발하는 것이다. 물론 시행착오를 겪겠지만, 본질적인 목표는 공부이기 때문에 오히려 좋다.

개념에 대해 조사를 하고, 본 글을 쓰면서 구글링을 해보면 매우 비슷한 내용의 글들이 보이는것을 알았다.
딱히 와닿는 느낌의 글은 별로 없었으며, 제대로 이해하기 위해선 켄트백의 TDD를 읽어와야겠다는 생각을 하게 되었다.

일단 개념적으로는 이정도까지만 생각해보고, 방법을 따라해보면서 프로젝트를 진행하며 내가 느낀바와 이론을 비교해보도록 해야겠다.

Add TODO
1. 켄트백의 TDD 읽기
2. TDD로 프로젝트 진행해보기