레거시 코드의 효과적인 단위 테스트 적용 방법

4.1 1단계: 현황 분석

정적 분석을 통해 코드의 현재 상태를 파악합니다.

분석 항목:

• 순환 복잡도(Cyclomatic Complexity) 분포
• MISRA 규칙 위반 현황
• 함수별 라인 수
• 전역 변수 사용 현황
• 외부 의존성

순환 복잡도의 경우, McCabe의 원 논문(1976)에서는 10 이하를 권장하였습니다. 자동차 소프트웨어 현업에서는 15~20을 기준으로 삼는 사례가 있으나, 이는 조직 및 프로젝트의 코딩 가이드라인에 따라 다릅니다. 설정된 기준을 초과하는 함수는 테스트 난이도가 높으므로 분할을 고려해야 합니다.

정적 분석은 코드의 구조적 문제와 코딩 규칙 위반을 식별하는 데 유용하지만, 런타임 동작을 검증하지는 못합니다. 따라서 정적 분석과 동적 테스트는 상호 보완적으로 적용되어야 하며, 정적 분석이 동적 테스트를 대체할 수는 없습니다.

4.2 2단계: 테스트 가능 영역 식별

코드를 테스트 용이성에 따라 분류합니다.

즉시 테스트 가능한 코드:

• 외부 의존성이 없는 순수 계산 로직은 별도의 준비 없이 테스트할 수 있습니다.

/* 순수 함수의 예 */
uint16_t CalculateCRC(const uint8_t* data, uint16_t length);
float32_t ConvertRawToPhysical(uint16_t rawValue, float32_t scale, float32_t offset);

Stub/Mock이 필요한 코드:

하드웨어나 외부 모듈에 의존하는 코드는 해당 의존성을 대체해야 테스트가 가능합니다.

• Stub: 테스트 대상이 호출하는 의존성을 고정된 응답을 반환하도록 대체한 것
• Mock: Stub의 기능에 더해, 호출 여부나 호출 횟수 등 행위(Behavior)를 검증할 수 있도록 한 것

/* 하드웨어 의존 코드의 예 */
uint16_t ReadADCValue(uint8_t channel)
{
    return ADC_REG->RESULT[channel];
}

위와 같은 함수는 테스트 시 ADC 레지스터를 Stub으로 대체하여 원하는 값을 주입할 수 있도록 해야 합니다.

4.3 3단계: 특성화 테스트(Characterization Test) 작성

특성화 테스트란 레거시 코드의 현재 동작을 기록하는 테스트입니다. 이 테스트의 목적은 코드가 “올바르게” 동작하는지 검증하는 것이 아니라, 현재 동작을 문서화하여 향후 변경 시 동작 변화를 감지하는 것입니다.

특성화 테스트 작성 절차:

1. 함수를 다양한 입력값으로 실행
2. 실제 출력값을 기록
3. 해당 출력값을 기대값으로 설정

void Test_CalculateSpeed_Characterization(void)
{
    /* 현재 동작을 기록한 테스트 */
    ASSERT_EQUAL(CalculateSpeed(100, 10), 10);
    ASSERT_EQUAL(CalculateSpeed(0, 10), 0);
    ASSERT_EQUAL(CalculateSpeed(50, 5), 10);
}

주의사항: 특성화 테스트 작성 시 정의되지 않은 동작(Undefined Behavior)을 유발할 수 있는 입력(예: 0으로 나누기, NULL 포인터 역참조 등)은 피해야 합니다. 이러한 입력에 대해서는 먼저 방어 로직이 있는지 확인하고, 없다면 방어 로직 추가를 선행하거나 해당 케이스를 테스트 범위에서 명시적으로 제외해야 합니다.

4.4 4단계: Seam 확보 및 커버리지 확장

Seam이란 코드를 변경하지 않고 동작을 바꿀 수 있는 지점을 의미합니다. Michael Feathers(2004)가 제시한 이 개념은 레거시 코드 테스트의 핵심 기법입니다. 각 Seam 유형의 특성을 이해하고 코드 상황에 맞는 방식을 선택합니다.

Link Seam: 링크 시점에 다른 구현으로 교체

• 적용: 테스트 빌드에서 실제 드라이버 대신 Stub 라이브러리를 링크
• 예: 프로덕션에서는 o, 테스트에서는 eeprom_stub.o 링크

Preprocessor Seam: 전처리기 지시문 활용

• 적용: 매크로로 함수 호출을 대체
• 예: #ifdef UNIT_TEST 블록 내에서 #define ReadEEPROM(addr) ReadEEPROM_Stub(addr)

Function Pointer Seam: 함수 포인터를 통한 의존성 주입

• 적용: 런타임에 의존성을 교체할 수 있도록 설계
• 예: typedef uint16_t (*ADC_ReadFunc)(uint8_t); ProcessData(ADC_ReadFunc reader);

일반적으로 Link Seam은 빌드 시스템 수정이 필요하고, Preprocessor Seam은 코드 가독성에 영향을 줄 수 있으며, Function Pointer Seam은 가장 유연하지만 기존 인터페이스 수정이 필요합니다. 기존 코드 변경이 어려운 경우 Link Seam이나 Preprocessor Seam을 먼저 고려합니다.

4.5 5단계: 리팩토링과 테스트의 선순환

특성화 테스트가 확보된 코드는 안전하게 리팩토링할 수 있습니다.

리팩토링 전:

void ProcessMessage(Message_t* msg)
{
    /* 200줄의 코드: 검증, 파싱, 처리, 응답 모두 포함 */
}

리팩토링 후:

bool ValidateMessage(const Message_t* msg);
ParsedData_t ParseMessage(const Message_t* msg);
Result_t HandleParsedData(const ParsedData_t* data);

void ProcessMessage(Message_t* msg)
{
    if (!ValidateMessage(msg)) return;
    ParsedData_t parsed = ParseMessage(msg);
    Result_t result = HandleParsedData(&parsed);
    SendResponse(CreateResponse(result));
}

분리된 함수는 각각 독립적으로 테스트할 수 있으므로 테스트 용이성이 향상됩니다.