how to start TDD how to maintain TDD

1. TDD or TFD
MMVENTURES 박영일

2. 테스트의 안내
테스트를 기반으로 개발을 진행하고 테스트로부터 피드백을 받는 데 집중

3. TDD는 뭐야?
TDD 시작하기
동작하는 골격
TDD 3가지 법칙
중첩된 고리형 시스템
기존 시스템 대상
TDD 유지하기
TDD and TAD
순 서

4. TDD는 뭐야? TDD 3가지 법칙
-> 단순히 결함을 예방하는 테스트 코드 X
-> 기능을 테스트하는 유닛테스트 X
-> 회기 테스트 X
-> TDD는 설계활동 O
-> TDD가 왜 설계활동이라 불리는지 지금부터
알아봅시다.
1) failing test가 있을 때에만 제품 코드를 작성해야한
다.
2) 테스트 코드를 작성시에 실패를 나타낼 수 있는
최소의 코드만 작성하라.
즉, 내가 원하는 기능이 동작하지 않는 경우를 나타낼
수 있을 정도만!
3) 2번의 failing test code가 딱 성공할 만큼만 제품 코
드를 작성하라.

5. TDD 시작하기
-> 어떻게 시작해? : 중첩된 고리형 시스템 만들기
중첩된 고리형 시스템
문제 이해 대략적인 설계
(아키텍처)
자동화
- 빌드
- 배포
- 전 구간 테스트
실패하는
인수 테스트
작성
실패하는
단위 테스트
작성
테스트
통과시키기
배포 가능
시스템
제품 출시
자동화된 빌드, 배포, 테스트 주기 전체를 구현해야한다.
 빌드, 배포, 테스트 주기 전체에 대한 피드백을 받기 위해서
피드백을 통해서 예상 가능했던 문제들은 예를들어 어떤것들?
 손으로 배포(일명 손배포)는 오류가 발생하기 쉬운 활동이므로 배포 과정의 자동화
 개발 팀이 조직의 다른 부분과 접촉하기도 하며, 운영이 실제로 어떻게 되는지도
배워야하므로 이 과정을 통해 피드백을 충분히 받아야한다.
리팩터링

6. 최초의 기능이 필요하다.
1) '동작하는 골격'을 대상으로 빌드, 배포, 테스트하는 방법을 파악
2) 그 기반 구조를 이용해 유의미한 첫 기능에 대한 인수테스트를 작성

7. 동작하는 골격
이것의 요구사항은 대략적인 시스템 구조를 제안하고 그것의 유효성을 검증할
수 있을 정도. 딱 그정도.
예) 가령 데이터 베이스를 활용하는 웹 어플리케이션이라면 골격에서는
데이터베이스 필드가 보여질 것이다.
*동작하는 골격의 외형 결정
 이것은 애플리케이션의 개괄적인 구조를 결정하기 시작한다는 의미다.
 어떤 전체 구조에 관한 구상 없이는 빌드, 배포, 테스트 주기를 자동화할 수 없다.
 주요 시스템 컴포넌트와 그러한 컴포넌트의 상호 작용 방식에 대한 대략적인 그림.
* 동작하는 골격의 핵심
 팀에서 코드 작성을 시작하기 전에 반드시 취해야 할 필수적인 의사결정을 첫 테스트를
작성하는 과정을 활용해 프로젝트의 맥락을 짚어내는 데 있다.
 이는 애자일 개발에서 좋지 않게 보는 " 과도한 사전 설계"와 혼동할 수 있다. 정교한
클래스 설계를 하는것이 아니라 단순히 현재 생각하고 있는 바가 틀릴 가능성이
있으므로 시스템이 성장해 가면서 세부 사항을 파알하는 방식을 선호하는 것.
 위 말은 불확실성을 일찍 드러내어 초기에 각종 쟁점을 드러낸다. But, 프로젝트
초기라면 시간과 예산, 쟁점을 해결할 의지가 있을 때!

8. 기존 시스템 대상
* 동작하는 골격을 만드는 것으로 프로젝트를 시작할 수 없다.
 기본 구조가 아무리 부적당해도 그것을 이용해야 한다는 의미
 일단은 빌드와 배포과정을 자동화한 다음, 변경하고자 하는 코드의 영역을 포괄하는
*전 구간 테스트*를 추가. 그렇게 코드 영역을 보호해 두면 좀 더 확신을 갖고 기능을
추가할 때마다 코드를 리팩터링하고 단위 테스트를 도입하며 내부 품질 문제를 해결.
* 전 구간 테스트 기반 구조를 구축하는 가정 쉬운 방법 : 시스템을 관통하는 가장 단순한
경로를 이용하는 것. TDD 유지하기 시작과 비슷

9. TDD 유지하기
새로운 기능 추가 -> 실패하는 인수테스트로 시작한다.
실패하는
인수 테스트
작성
실패하는
단위 테스트
작성
테스트
통과시키기
실패하는 인수테스트로 시작한다.
=> 당연히 구현이 되지 않았으므로 인수 테스트는 실패
리팩터링
< TDD 주기 유지 >

10. 실패하는
단위 테스트
작성
테스트
통과시키기
리팩터링
테스트 코드는 가장 간단하고 사소한것부터 쓸때없는 것 -> 어렵고 중요한 것
1) 빨리 녹색을 볼 수 있어 기분이 좋아진다.
2) 어렵고 중요한 테스트 코드부터 작성하게 된다면 나중에 쉬운 case를 테스트할 수가
없다. 그리고 이미 다 되어있거나 그것만 따로 분리시킬 수 있는 구조가 아님.
RED GREEN
BLUE
나중에 시간될때?
지금해!!빾!!!!

11. TDD and TAD
TDD의 좋은 점.
1.디버깅 시간 단축
2.Decoupling
3.change to courage
4.trust(테스트는 낙하산에 비교)
TAD의 안좋은 점.
1. 신뢰할 수 없다.
2. 불안하다.
3. Test code를 작성하는 시간이 지루하다.
4. 그 시간이 낭비적으로 느껴진다.
당신은 낙하산을 만들고 뛰어내릴 것인가. 뛰어내린 뒤에 낙하산을 만들것인가.

12. Q n A

13. Live coding start…