총 2부로 구성.
1부는 멋사 / 2부는 야곰
멋사
출처 : https://www.youtube.com/watch?v=xs-yhBlkbbQ
익스트림 프로그래밍
전통적인 waterfall방식과 달리, 요구사항이 급변하는 분야에 적합한 개발 방법론을 말하며
이 방법론들 중 하나가 TDD이다
(그 외 : Whole Team / Simple Design / Pair Programming 등)
TDD가 특장점을 많이 갖고 있어서 TDD가 대중화되고 중요시됨
TDD 정의
Test Code를 먼저 짜고 Production Code를 짜는 방법
(test case를 먼저 만들고 코드를 짠다)
구체적인 방법
- 요구사항 파악
- 그에 맞게 테스트 케이스 및 코드 작성
- 테스트 코드가 돌아가도록 Production code 작성
- 리팩터링을 통해 코드를 좀 더 간결하고 읽기 쉽게
- 다시 1번부터
TDD의 장.단점
-
처음부터 미래의 요구사항을 모두 예측해야 하므로 필요없는 기능이 들어가는 오버 엔지니어링 유발
-
해외취업에서 중요시여겨짐
-
오픈소스엔 자체 테스트 코드들이 있으므로 contributor가 되려면 이 테스트 코드 자체에 대해 아는 것도 굉장히 중요
-
코드가 동작한다는 것에 대한 자신감up. 전통적인 방식에선 이게 잘 돌아갈지 당장 알 수 없음
-
오버 엔지니어링을 피하고 간결성 증대
-
테스트 코드 자체가 code에 대한 문서가 될 수 있음 (실행 가능한 문서를 얻는 것)
-
유연한 설계, 의존성 관리 (테스트 코드 기반으로 작성하면 오히려 의존성을 유발하기 굉장히 어려워진다)
야곰
겹치지 않는 부분만 기록
TDD 개발 cycle에서 RED는 "실패하는 테스트"를 작성하는 것
언제 실패하는지를 정의함으로써 테스트 신뢰성을 검증하는 방식. 성공만 가지고는 테스트를 검증할 수 없으므로 실패를 의도적으로 유발
즉, RED단계에선 우선 production code를 이상하게 짜서 "테스트 코드 검증"부터 한다
한 번에 성공은 불가하다. 역으로 빠르게 실패하여 개선시점을 당기자
테스트 케이스 자체가 좋은 문서가 된다
테스트 케이스를 보면 이 app/메서드가 어떤 기능을 하는지 쉽게 추론할 수 있다
테스트를 먼저 작성해야 하는 이유
테스트 케이스를 짜려고 노력하면 요구사항을 정확히 이해할 수 있다.
코드 작성부터 하면 테스트를 고려하지 않고 만들었기에 테스트 자체가 불가한 코드가 만들어질 수 있다
First
Fast
Indepedent : 각 test는 서로 독립적일 것
Repeatable : 반복해도 같은 결과
Self-validating
Timely..?
TDD가 결국은 가장 빠르다
테스트 코드짜느라 시간이 더 걸릴 것 같지만, 결국은 이게 빠르다 (특히 규모가 커질수록)
