The RED : 이규원의 현실 세상의 TDD - 테스트 주도 개발 기초 === ###### tags: `석기` --- ## 코드 기능 명세 ### 도메인이란? 소프트웨어는 문제를 푸는 도구. **소프트웨어가 풀어야 할 문제가 정의되는 공간** #### 비즈니스 전문가 - 문제를 가장 잘 이해 - 문제 설명력 부족 - 풀이도 가장 잘 이해한다고 **착각** #### 분석가 - 비즈니스 전문가로부터 시스템 요구사항 발굴 - 해당 요구사항이 어떤 방향성을 가지는지 / 가능한지 판단. #### 프로그래머 - 정제된 기능 명세를 아키텍처와 코드로 번역 - 끊임없는 설계 결정 - 지식 흐름과정의 마지막 인간 ### 컴퓨터 - 코드를 토해 프로그래머로부터 지식을 받음 - 로우 레벨. ### 단위 테스트 작성 실습 #### 분산을 계산하는 프로그램. - 데이터가 없을때 - 데이터가 하나만 있을때 >[color=#57e5ae] 버그 발생. --- ## 테스트 기법 ### 수동 테스트 - 품질 담당자가 UI를 사용하여 기능을 검증 - 최종 사용자의 사용 경험과 가장 비슷하게 검증 - 실행 비용이 높고 결과의 변동이 큼 - 가장 온전한 코드 실행 - 인수 테스트 #### 소프트웨어 회귀 - 특정 이벤트 후에 갑자기 소프트웨어에 버그가 생기는 것 ### 테스트 자동화 - 기능을 검증하는 코드 작성 - 실행 비용이 낮고 결과의 신뢰도가 높음 - 프로그래머 역량에 크게 영향을 받음. ### 인수 테스트 - 배치된 시스템을 대상으로 검증. - 전체 시스템 이상 여부 신뢰도가 높음 - 높은 비용 - 피드백 품질이 낮음 ### 단위 테스트 - 시스템의 일부를 대상으로 검증 - 낮은 비용 - 높은 피드백 품질 - 전체 시스템 이상 여부 신뢰도가 낮음 --- ## 코드 분해 - 왜 개발자들이 코드를 분해할까? ### 코드 재사용 - 반복되는 문제의 풀이는 재사용 가능 - 소프트웨어 개발 비용 절감 ### 모듈화 #### 분해 - 큰 시스템은 작은 하위로 분해 - 교체 가능 #### 조립 - 작은시스템은 큰 시스템으로 조립 - 모듈 재사용 - 라이브러리 --- ## 단위 테스트 - 전체 시스템의 일부를 테스트하는 기법. **Jest**를 활용하여 테스트 진행. ==parameterized test== --- ## 테스트 우선 개발 ### 테스트 코드를 운영코드보다 먼저 작성하는 기법. - 명확하고 검증 가능한 목표를 설정한 후 목표를 설정. - 프로세스가 코딩에 앞선 목표 설정을 강요 - 프로그래머는 자신이 풀어야할 문제를 구체적으로 이해하여야 함. --- ## 정리된 코드 ### Refactoring? - 의미를 유지하며 코드 베이스를 정리. - 모듈화 / 로컬 함수로 분리 - 반복된 작업 함수로 분히 --- ## 테스트 주도 개발 ### 테스트 주도 개발 절차 1. RED - 실패하는 테스트 추가 - 구체적인 하나의 요구사항을 검증하는 하나의 테스트 추가 - 추가된 테스트가 실패하는지 확인 - 이때 실패의 요인은 운영 코드의 오류여야함. 2. GREEN - 테스트 통과 - 추가된 테스트를 비롯해 모든 테스트가 성공하도록 운영코드 변겅 - 최소한의 코딩 - 가장 중요한 임무를 가장 빠르게 변경 3. BLUE - 리팩토링 - 코드 베이스 정리 - 구현 설계 개선 - 가독성 - 적응성 - 성능 - 모든 테스트 성공을 전제 ### 테스트 주도 개발 세부 흐름 <img width="941" alt="image" src="https://user-images.githubusercontent.com/52649378/162987483-e987136d-fd1b-48b1-8e04-5434ab896ec8.png"> ### 테스트 주도 개발은 낯설지 않다. ### 테스트 주도 개발의 비용 - TDD를 사용하지 않는다면 - 시작할 땐 공수가 낮지만 - 시간이 흐르면 공수가 더 들어간다. - TDD를 사용한다면 - 시작할 땐 공수가 높지만 - 유지보수가 원활하다. --- ## 프로그래머 피드백 #### 오버 엔지니어링 - 프로그래머는 달성에 목표를 두고 - 구현 설계 품질 개선에 빠져드는 경향을 가짐. - 이 속성이 지나친다면 **불필요하게 자원을 낭비하게 됨** - TDD는 가장 중요한 목표를 우선 달성하도록 유도. - 오버엔지니어링에 빠졌음을 느낄때 안심하고 다음으로 나아갈 수 있도록 **피드백을 제공.** ### 핵심은 피드백! - TDD의 핵심은 정해진 절차가 아니라, - **짧은 주기로 지속되는 피드백**이다. - ==피드백에 기반해 안정적으로 지식과 코드를 늘려 나가는 것이 목적.==