---

TDD 정리 2탄 - 실전과 프레임워크의 이해

---

✅ TDD - Learned vs Execution

구분	설명
Learned (학습용 테스트)	- Mock/Fake 인터페이스로 조건 주고 테스트 케이스 실행 - 디버거 사용 없이도 개발 가능
Real Execution (실행 환경 테스트)	- 시스템을 모킹하는 대신 시스템 자체를 Fake 처리 - 시스템 API와 모듈 API를 모두 Fake - 쓰레드나 컴파일러 의존 부분은 실제 동작과 다를 수 있음 - 디버깅은 여전히 중요: 테스트 유지보수의 핵심

---

🛠️ Tizen Native App 개발 도구 선정

후보 도구	평가
Source Insight	정적 분석에 적합
VS Code	C#/Native 모두 지원
Visual Studio (C++)	최종 선택 · 빠른 디버깅 · TDD 프레임워크 유지에 핵심 · 최적화된 에디터

⚠️ gTest 빌드 이슈

• 링크 에러: 소프트 링크 → 경로가 256자 초과
• 해결: 상대 경로와 소스 구조 수정

---

🔌 시스템/모듈 Dependency Fake

시스템 종속 API Fake

• Ecore Timer, std::thread, Callback, Remocon, Vconf, System Info
• Submicom: virtual 상속으로 Fake
• DBUS, FileInfo

다른 모듈 Fake

• HDMI Control, Audio, App Manager, KPI Logger
• Power, AVOC, AppControl, SoundManager, AOV, VirtualChannelAPI, TVSServiceUtility

---

⚙️ TDD Helper 유틸

• 어떤 위치에서도 정보 접근 가능
• private/protected -> public 전환
• 시스템/모듈 API → Helper Class로 추상화
• 기본 설정값 적용 → 사전 조건 줄이기

---

📋 TDD 개발 절차

Step 1 - Fake 구현

1. 의존 API 동작 파악
2. Fake 구현
3. 전체 빌드 성공

Step 2 - TC 작성

1. 내 코드 이해 & 리팩토링
2. TC 작성: 조건 설정 → 실행 → 결과 확인
3. 통과 시도 (Make it pass)
4. 코드 제출
5. 유틸성 코드 리팩토링

---

🧪 예제 TC - CEC 1.4 인증

TEST(SystemAudioModeTest, SetStreamPath_SHOULD_NOT_BE_REPLIED)
{
    CECSubmicomMock cecSubmicomMock;
    CECMainMock cecMain(&cecSubmicomMock);
    TDDUtil tddutil(&cecMain);

    cecMain.Initialize();

    CECMessage cMsg1 = { 0xe0, 0x86, 0x12, 0x00 };
    tddutil.GetCECMsgReceiver()->m_ProcessCECMsg(cMsg1, 4);

    EXPECT_EQ(0, tddutil.GetSubmicom()->m_count.m_feature_abort);

    cecMain.Uninitialize();
}

코드 처리부

void CCECMsgReceiver::DefaultMsgProcessing(const CECMessage& cMsg)
{
    if (cMsg.m_opcode == OPCODE_SET_STREAM_PATH) {
        ERR("Recv <SetStreamPath>. should not be replied");
    }
}

---

🔥 TC 깨지는 경우 (Unhappy case)

• 시장 정책 변경 → 스펙 수정
• 기존 TC 실패 → 이전 디바이스 동작 이해 부족
• 실제 대상 우선 테스트 후 TDD 수정

---

🗂️ TDD vsproj 관리

• Fake / UnitTest / Main 프로젝트 명확히 분리
• 실 제품 빌드 vs TDD 테스트 빌드 분리
• 브랜치도 분기: 실코드 vs TDD 코드

---

🧾 TDD Ground Rules

규칙	설명
공통 도구 사용	다른 에디터 금지 (ex. vi, Notepad++)
동일 프로젝트 사용	로컬 프로젝트 금지, 공통 단축키 사용
클린 코드 준수	2줄 간격, 1줄 간격 등 통일된 코드 스타일
모든 코드 변경 → TC 작성 필수	신규 TC + 기존 TC 통과 여부 검토
리뷰 항목에 TC 포함	신규/전체 TC 결과 포함, 예외 처리 명시
코드 동기화 철저	모든 브랜치 및 메인과 동기화 유지

---

❗ TDD의 어려움

• 사전 조건 vs 실제 조건 불일치
  → 외부 시스템 더 깊이 이해 필요
• 타겟 테스트 여전히 필요
  → 성능, 타이밍, 쓰레드 등
• 수많은 TC 실패 → 1 fix = 다수 영향
  → 도메인 오너/PL 적극 개입 필요
• 레거시 코드 리팩토링 시 Side Effect
  → 반드시 QA 전체 테스트 진행

---

🚀 Do vs Doing TDD

구분	설명
Do TDD (지시로 함)	"했어요!"로 끝나는 TDD
Doing TDD (자발적 실행)	내 코드 품질에 대한 불신 → TC와 함께 점검 진짜 개발자 마인드

---

🎯 성공의 숨겨진 열쇠

Visual Studio

• 빠른 로컬 빌드 & 디버깅
• GUI 디버깅 → 스트레스 감소
• 성능 좋은 PC 필수

도메인 오너/PL

• 명확한 변수 설명 (e.g., retry count, timer)
• 내부 상태 명시 필요

---

🧩 Tips

주제	팁
디버깅	호출자는 항상 호출 이유를 제공해야 함
void 반환 함수	테스트 가능성을 위해 return 값 만들기

---

🎁 진짜 TDD의 가치

항목	설명
테스트 안되면, 안전도 없음	기본 자세: '나도 믿지 마!'
두려움 → 자신감	1번은 실수 가능, 2번은 없다
연속된 성공	아트급 코드 + 개발의 재미
가장 큰 가치	테스트 프레임워크 자체 → 진짜 코딩과 검증을 가능하게 하는 도구

---