fastcampus TDD 학습 01
개발 방식에 문제는 없지만 혼자 개발하는 일이 많아지면서 TDD를 적용하기로 마음먹었다. 그 이유는 이규원님이 당신들의 TDD가 실패하는 이유를 보다가 지금의 내상황에과 비슷하다고 생각했다. 적용하기 전에 학습부터!
적용하기 위해 현실 세상의 TDD 강의 를 회사에 요청하여 구매했고 사내 개발자들과 공유하기 위해 정라하도록 하겠다.
- 테스트 주도 개발 기초
Table of Contents
기능 명세란
입력과 출력에 대한 기대 동작들
코드의 명세 또는 요구사항
도메인
- 소프트웨어가 풀어야할 문제가 정의되는 공간
- 도메인에서 출발함
- 문제를 충분히 이해하지 못하면 문제를 푸는 도구를 만들 수 없다
- 도메인 지식 흐름
- 비지니스 전문가 -> 분석가(제품 관리자/서비스 기획자/프로그래머) -> 프로그래머 -> 컴퓨터
- <- 목적/추상적 ————————————————————– 수단/구체적 ->
프로그래머와 기능 명세
- 도메인 지식을 컴퓨터에 전달할 때엔 모든 요소들이 명확히 결정될 수 밖에 없음
- 명확한 도메인 지식을 확보하지 못한 프로그래머는 지식 흐름 상류에 지식 보강을 요청해야함
- 스스로 결정을 내리면 도메인 지식 투영에 오차를 발생 또는 무책임하고 위험한 도박임
테스트 기법
- 수동테스트
- QA가 하는 일
- 최종 사용자의 사용 경험과 가장 비슷하게 검증
- 가장 온정한 코드 실행
- 인수 테스트로 사용됨
- 단점 : 실행 비용이 높고 결과의 변동이 큼
- 회귀테스트
- 환경의 변화에 따라 기존 기능이 오작동 하는 경우
- 시간이 지날수록 회귀테스트 대상이 늘어남
- 테스트 자동화
- 기능을 검증하는 코드를 작성(사람 대신 코드가 테스트함)
- 테스트 코드 작성 비용이 소비
- 실행 비용이 낮고 결과의 신뢰도가 높음
- 테스트 코드 작성과 관리가 프로그래머 역량에 크게 영향을 받음
- 인수 테스트
- 배치된 시스템을 대상으로 검증(현장과 동일하거나 유사한 상태로 테스트)
- 전체 시스템 이상 여부 신뢰도가 높음
- 높은 비용, 피드백 품질이 낮음
- 단위 테스트
- 시스템의 일부를 대상으로 검증
- 낮은 비용, 높은 피드백 품질
- 전체 시스템 이상 여부 신뢰도가 낮음
코드 분해
- 문제의 크기
- 코드 재사용
- 반복되는 문제의 풀이는 재사용 가능
- 소프트웨어 개발 비용 절감
- 모듈화
- 분해
- 큰 시스템은 더 작은 하위 시스템으로 분해/교체 가능
- 조립
- 작은 시스템은 더 큰 사위 시스템으로 조립가능
- 모듈 재사용 가능
- 라이브러리화 가능
- 단위 테스트
- 분해
테스트 코드
- 가시적이고 구체적인 목표
- 자가검증
- 반복실행
- 클라이언드
- 운영 코드보다 테스트 코드를 먼저 작성(테스트 우선 개발 이라고 함)
- 명확하고 검증 가능한 목표를 설정한 후 목표를 달성
- 프로세스가 코딩에 앞선 목표 설정을 강요
- 프로그래머는 자신이 풀어야 할 문제를 구체적으로 이해해야함
작업 환경 정리/리팩터링
- 정리된 환경에서의 작업 생상성이 높다
- 작업 환경의 생산성이 일정 수준 미만으로 떨어지면 더 이상 그 환경에서 작업 진행은 불가능
- 코드 == 작업환경, 코드 == 작업 결과물
- 코드작업에서 작업 환경 정리는 리팩터링이라고 부름
- Re-factoring은 의미를 유지하며 코드베이스를 정리
- 의미 유지를 확인하는 방법은 테스트
테스트 주도 개발
- RED -> 실패하는 테스트 추가
- GREEN -> 테스트 통과, 최소한의 코딩
- REFACTOR -> 구현 설계 개선, 테스트 통과 유지
- 테스트 실패
- 구체적인 하나의 요구사항을 검증하는 하나의 테스트를 추가
- 추가된 테스트가 실패하는지 확인
- 테스트 성공
- 추가된 테스트를 비롯해 모든 테스트가 성공하도록 운영 코드를 변경
- 테스트 성공은 요구사항 만족을 의미
- 테스트 성공을 위한 최소한의 변경
- 리팩터링
- 코드베이스 정리
- 구현 설계 개선(가독성, 적응성, 선능)
- 모든 테스트 성공을 전제
- 핵심은 피드백
- 정해진 절차가 아니라 짧은 주기로 지속되는 피드백
- 피드백에 기반해 안정적으로 지식과 코드를 늘려 나가는 것이 목적