고품질 쾌속개발을 위한 TDD 실천법과 도구 - 1장 내용을 스스로 이해하기 위해 작성하는 글입니다.
1.1 일반적으로 우리의 개발은 다음과 같다.
우리 개발자 자신의 두뇌는 명석하기때문에 개발을 하면서, 문제영역을 발견한다. 문제영역을 발견하고, 이를 해결하기 위해 '기능을 구현' 하고, 일정 시간이 지나면 구현의 '검증' 을 위한 테스트를 수행합니다. 대표적인 방식은 "콘솔에 값 찍어보기?"
위와같이 했을 경우, 주의해야 될 부분으로 문제의 해결 유무 판단을 우리의 두뇌가 하려고 한다는 것이다.
여기서 문제점이 발생한다. 사람의 머리란 간사해서- 상황에 따라서 다른 반응을 하고, 효율도 그때그때 다르다.
고전적인 개발 방식에서의 문제점은 다음과 같다.
1. 특정 모듈의 개발 기간이 길어질수록 개발자의 목표의식이 흐려진다.
- 어디까지 짰더라?
- 아, 내가 지금 뭘 하는 거였지?
- 이 모듈이 모슨 기능을 해야 한댔더라?
2. 작업 분량이 늘어날수록 확인이 어려워진다
- 로그가 어디있더라?
- 이것도 화면으로 출력해보고
3. 개발자의 집중력이 필요해진다
- 앗! 화면 지나갔다!
4. 논리적인 오류를 찾기가 어렵다
- 여기서 그러니까 이 ㄱ밧이 들어가면 나와야 하는 게...!
5. 코드의 사용 방법과 변경 이력을 개발자의 기억력에 의존하게 되는 경우가 많다.
- 맞아! 개인고객 인증을 고치면 법인 고객인증 부분도 함께 고쳤어야 했었지!!
6. 테스트 케이스가 적혀 있는 엑셀 파일을 보며 매번 테스트를 실행하는 게 점점 귀찮아져서 는 점차 간소화하는 항목들이 늘어난다.
- 날짜? 1111. 주민번호? 우선 222222-2222222. 주소? 서울 개똥이네
7. 코드 수정 시에 기존 코드의 정상 동작에 대한 보장이 어렵다.
- 휴~ 찾았다. 여길 고쳐야 하는 거였군! 아, 근데 이 금칙어 필터 모듈 혹시 다른 데서도 쓰는 거 아냐?
8. 테스트를 해보려면 소스코드에 변경을 가하는 등, 번거로운 선행 작업이 필요할 수 있다.
- 입고 처리를 테스트하려면, 주문이 완료됐다고 테이블에 직접 업데이트를 해줘야…
9. 그래서 소스 변경 시 해야 하는 회귀 테스트3 는 곧잘 희귀 테스트(rare test)가 되기 쉽다.
- 아, 그걸 언제 다 다시 테스트해? 우선 급한 불부터 끄고 보자구. 집에 안 갈거야?
10. 이래저래 테스트는 개발자의 귀중한 노동력(man-month)을 적지 않게 소모한다.
- 품질(QA) 담당자 가라사대: 소스 수정사항 생기면 엑셀에 적힌 단위 테스트 다시 수행하는 걸 절대! 빼먹지 마!(그리고 자꾸 빼먹으면 재미없어질 거라는 눈빛!)
이런 문제점을 해결하기 위해 TDD가 출연하게 됐다.
프로그램을 작성하기 전에 테스트 먼저 하라! - 켄트 백
1.2 테스트 주도 개발(Test-Driven Development, TDD)
테스트 주도 개발은 어떻게 하는거람??
흔히 개발을 하는데 있어서, 머릿속으로 생각하는 내용을 위와같이 일종의 설계문서처럼 만들었다. 이제는 이것을 "문서로 만들어 머리로 생각하고 눈으로 확인할 것인가?" 아니면 "예상 결과를 코드로 표현해놓고 해당 코드가 자동으로 판단하게 할 것인가?" 의 차이가 바로 TDD의 시작이다.
꼭 테스트 프레임워크를 써야하는 것이 아니며- 테스트 케이스 작성으로 구현을 시작하는 것, 그게 바로 TDD이다.
1.3 테스트 주도 개발의 목표
TDD의 최종 목적은 "잘 동작하는 깔끔한 코드" 이다. TDD에서는 정상적으로 동작하는 코드만을 개발의 목표로 삼지 않고, 작성된 코드도 명확한 의미를 전달할 수 있게 작성돼야 한다고 말한다. 즉, '제대로 동작함(works)' 뿐 아니라 '깔끔함(clean)'까지도 동등한 수준의 개발 목표로 삼는다는 점이 일반적인 개발 방식과 다르다.
1.4 개발에 있어 테스트 주도 개발의 위치
개발자 가 처음으로 수행하는 테스트
개발자가 자신을 위해 처음으로 수행하는 테스트, 흔히 개발자 테스트 라고도 합니다.
1.5 테스트 주도 개발의 진행 방식
- 질문(Ask) - 테스트 작성을 통해 시스템에 질문한다(테스트 수행 결과는 실패)
- 응답(Respond) - 테스트를 통과하는 코드를 작성해서 질문에 대답한다. (테스트 성공)
- 정제(Refine) - 아이디어를 통합하고, 불필요한 것은 제외하고, 모호한 것은 명확히 해서 대답을 정제한다. (리팩토링)
- 반복(Repeat) - 다음 질문을 통해 대화를 계속 진행한다.
1.6 코드로 먼저 시작해보기.
1.7 TDD의 장점
■ 개발의 방향을 잃지 않게 유지해준다
■ 품질 높은 소프트웨어 모듈 보유
■ 자동화된 단위 테스트 케이스를 갖게 된다
■ 사용설명서 & 의사소통의 수단
■ 설계 개선
■ 보다 자주 성공한다
'아직 카테고리 미정' 카테고리의 다른 글
| Mock 객체란 무엇일까? 왜 써야될까? (0) | 2021.03.11 |
|---|---|
| TDD 좀 더 잘하기 (0) | 2021.03.11 |
| TDD로 XUnit 만들어 내기 - 1 (0) | 2021.02.25 |
| 테스트 더블을 강력한 위력을 이해해보자. (0) | 2020.12.28 |
| [마틴파울러]GivenWhenThen 번역본 (0) | 2020.12.27 |
댓글