테스트 주도 개발 (TDD)

• 실패하는 테스트를 먼저 작성합니다. 현재 구현되어 있지 않거나, 의도적으로 잘못된 동작을 테스트하는 코드를 작성합니다.
• 이 테스트는 실행했을 때 반드시 실패해야 합니다. 실패하지 않는다면, 테스트 자체가 잘못되었거나, 이미 기능이 구현되어 있는 경우입니다.
• 이 단계에서 작성하는 테스트는 개발하려는 기능의 명세를 정의하는 역할을 합니다.

• 테스트를 통과시킬 수 있는 최소한의 코드를 작성합니다.
• 이 단계에서는 오직 테스트를 통과시키는 것에만 집중하고, 코드의 아름다움이나 일반화는 고려하지 않습니다. 가장 빠르고 간단한 방법으로 테스트를 통과시킵니다.
• 테스트를 실행했을 때 성공해야 합니다.

• 코드를 개선합니다. 테스트가 모두 통과하는 상태이므로, 안심하고 코드를 리팩터링할 수 있습니다.
• 중복 제거, 가독성 향상, 설계 개선, 성능 최적화 등을 수행합니다.
• 리팩터링 후에도 모든 테스트가 여전히 성공하는지 확인합니다. 실패한다면 리팩터링이 잘못된 것이므로 되돌리거나 수정해야 합니다.

• 작성한 테스트가 다루는 행동의 회귀를 빠르게 찾을 수 있습니다. 모든 코드·입력·통합 경로의 커버리지를 자동으로 보장하지는 않습니다.
• 테스트가 없는 코드에 비해 리팩터링이나 기능 추가 시 변경에 대한 두려움을 줄여줍니다.

• 테스트를 먼저 작성하면서 코드의 외부 API(인터페이스)를 먼저 고민하게 됩니다. 이는 사용하기 쉬운 API와 응집도 높은 모듈을 설계하는 데 도움이 됩니다 (OCP, ISP, DIP와 연관).
• 복잡한 기능을 한 번에 구현하기보다, 테스트를 통해 작은 단위로 쪼개어 구현하게 되므로 설계가 점진적으로 개선됩니다.

• 기능 구현과 동시에 테스트를 통해 즉각적인 피드백을 받을 수 있습니다. 이는 문제점을 조기에 발견하고 해결하는 데 도움을 줍니다.

• 테스트 스위트가 일종의 안전망 역할을 하므로, 개발자는 마음 놓고 코드를 개선하고 최적화할 수 있습니다. 테스트가 관찰하는 범위의 회귀를 확인할 수 있으며, 테스트 밖의 동작도 고려해야 합니다.

• 잘 작성된 테스트 코드는 해당 기능의 작동 방식과 기대되는 동작에 대한 훌륭한 예시이자 문서 역할을 합니다.

src/utils/string.test.ts 파일 생성

import { capitalize } from './string'; // 아직 존재하지 않는 함수 임포트

describe('capitalize', () => {
  it('should capitalize the first letter of a string', () => {
    expect(capitalize('hello')).toBe('Hello');
  });

  it('should return an empty string for an empty input', () => {
    expect(capitalize('')).toBe('');
  });

  it('should handle strings with leading spaces', () => {
    expect(capitalize('  world')).toBe('  World');
  });

  it('should return the same string if the first character is not a letter', () => {
    expect(capitalize('123test')).toBe('123test');
    expect(capitalize('!abc')).toBe('!abc');
  });

  it('should handle single character strings', () => {
    expect(capitalize('a')).toBe('A');
  });
});

이제 npm test를 실행하면 아직 없는 모듈·export 때문에 실패할 수 있습니다. 이 결과로 반환값 요구를 관찰했다고 판단하지 않습니다. 모듈을 만들고 아래 임시 함수를 넣어 테스트가 실제 구현까지 도달하게 합니다.

export function capitalize(str: string): string {
  return str;
}

이제 'hello'의 실제 값은 'hello', 기대값은 'Hello'여서 실패합니다. 빈 문자열·숫자·기호 테스트 일부가 통과해도 영문자와 앞 공백 요구가 실패하므로 스위트는 Red입니다. 설정·임포트 오류와 이 행동 실패를 구별한 뒤 구현을 바꿉니다.

src/utils/string.ts 파일 생성

export function capitalize(str: string): string {
  if (str.length === 0) {
    return '';
  }
  // 가장 간단하게 첫 글자만 대문자로 바꾸는 로직
  return str.charAt(0).toUpperCase() + str.slice(1);
}

npm test를 다시 실행합니다.

원문 구현은 첫 문자인 공백만 대문자화하므로 capitalize(' world')는 그대로 ' world'입니다. 따라서 앞 공백을 유지하며 W를 대문자화하라는 테스트에는 실패하고, 아직 Green이 아닙니다. trimStart()로 결과를 만들면 앞 공백이 사라지므로 그것만으로도 기대값을 충족하지 않습니다. 앞 공백을 보존한 채 첫 비공백 문자를 처리하는 구현이 필요합니다.

빠진 Green 단계 완성하기

앞의 첫 문자 구현을 기록해 둔 뒤, 작업 파일 src/utils/string.ts에서는 capitalize를 아래 별도 보완 구현으로 교체합니다. 같은 이름의 두 함수를 한 파일에 함께 선언하지 않습니다. 이 실습은 앞서 제시한 ASCII 문자열과 공백 조건을 다룹니다.

export function capitalize(str: string): string {
  const first = str.search(/\S/);
  if (first === -1) {
    return str;
  }
  return str.slice(0, first)
    + str.charAt(first).toUpperCase()
    + str.slice(first + 1);
}

먼저 비공백 위치를 찾습니다. 빈 문자열이나 공백만 있는 문자열이면 −1이어서 입력을 그대로 반환합니다. ' world'에서는 위치 2 앞의 두 공백을 보존하고 w를 W로 바꾼 뒤 orld를 붙입니다. trimStart는 탐색과 달리 반환값에서 공백을 제거하므로 같은 계약이 아닙니다. 앞의 6개 expect 결과가 모두 일치한 뒤에 구조 정리 단계로 넘어갑니다.

이 구현으로 통과를 예상하는 것과 독자의 프로젝트에서 Jest가 실제 통과한 것은 구별합니다. npm test로 첫 파일의 전체 테스트 결과를 확인하고 npx tsc --noEmit으로 정적 검사도 따로 수행하세요. package.json의 scripts만 병합할 때 기존 devDependencies를 지우지 않습니다. 교재에 제시한 Jest 29 계열 설정과 다른 최신 버전을 설치했다면 해당 버전의 변환기 설정을 대조합니다.

앞 공백 테스트까지 통과시킨 뒤 리팩터링해야 합니다. 아래 구현은 앞서 찾은 첫 비공백 위치를 유지하면서 접두 공백·대상 문자·나머지를 이름 있는 값으로 분리합니다. 첫 위치를 다시 0으로 바꾸면 기존 공백 요구가 깨지므로 그것은 동작 보존 리팩터링이 아닙니다.

하지만 더 복잡한 함수였다면 이 단계에서 다음과 같은 작업을 할 수 있습니다.

• 변수 이름 변경, 함수 분리
• 중복 코드 제거
• 가독성 향상
• 성능 최적화 (단, 테스트 통과가 유지되는 선에서)

숫자·기호 시작은 기존 기대값처럼 유지합니다. 새로운 문자 범위나 정규화 정책이 필요하면 리팩터링에 끼워 넣지 않고 다음 Red 단계의 별도 요구로 다룹니다.

export function capitalize(str: string): string {
  const first = str.search(/\S/);
  if (first === -1) {
    return str;
  }
  const prefix = str.slice(0, first);
  const firstChar = str.charAt(first);
  const rest = str.slice(first + 1);
  return prefix + firstChar.toUpperCase() + rest;
}

리팩터링 후에도 npm test를 다시 실행하여 모든 테스트가 여전히 통과하는지 확인합니다.

src/utils/string.test.ts에 새로운 테스트 블록 추가

// ... capitalize tests ...

import { reverseString } from './string'; // 이제 reverseString도 임포트

describe('reverseString', () => {
  it('should reverse a given string', () => {
    expect(reverseString('hello')).toBe('olleh');
  });

  it('should return an empty string for an empty input', () => {
    expect(reverseString('')).toBe('');
  });

  it('should handle single character strings', () => {
    expect(reverseString('a')).toBe('a');
  });

  it('should handle strings with spaces', () => {
    expect(reverseString('hello world')).toBe('dlrow olleh');
  });
});

npm test 실행 시 reverseString이 정의되지 않았다는 오류 발생 (Red 상태).

// 앞의 완성된 capitalize 구현은 그대로 두고 다음 함수만 추가합니다.
export function reverseString(str: string): string {
  // 가장 간단한 방법으로 뒤집기
  return str.split('').reverse().join('');
}

제시한 ASCII 범위의 reverseString 기대값은 이 구현과 일치합니다. 다만 전체 스위트가 Green이 되려면 앞서 남은 capitalize 실패도 먼저 해결해야 합니다. 실제 실행 결과를 제시한 것은 아닙니다.

작업 파일에는 보완한 capitalize를 유지하고 reverseString만 추가합니다. 위 블록을 추가하면서 기존 capitalize를 빈 함수로 덮어쓰지 않습니다. split('')은 UTF-16 코드 단위로 나누므로 emoji·결합 문자까지 사용자가 보는 글자 단위로 뒤집는 일반 구현으로 확장해 읽지 않습니다.

reverseString 역시 현재는 간결하므로 크게 리팩터링할 부분은 없습니다.

만약 성능이 중요한 상황이라면, split().reverse().join() 방식 대신 루프를 사용하는 방식으로 변경할 수도 있습니다.

중요한 것은 변경 후에도 테스트가 모두 통과하는지 확인하는 것입니다.

다음 요구를 독립적으로 검증하기

capitalize(' \tcode'), capitalize(' '), reverseString('ab cd')의 기대값을 먼저 쓰고 테스트를 추가해 보세요. 앞 공백과 탭은 그대로 두고 첫 비공백 영문자만 바꾸며, reverseString은 앞의 ASCII 뒤집기 계약을 유지합니다. 기대값을 맞추려고 입력을 미리 trim하지 않습니다.

이러한 Red-Green-Refactor 사이클을 반복하면서 점진적으로 기능을 추가하고 코드를 개선해 나가는 것이 TDD의 핵심입니다.