테스트 / 자동화
TDD(Test-Driven Development)
TDD는 원하는 동작을 검사하는 실패하는 테스트를 먼저 만들고, 통과하도록 구현한 뒤 코드를 정리하는 개발 방식입니다.
쉬운 설명
AI가 코드를 만든 뒤 잘됐는지 확인하는 순서를 바꿔 볼 수 있어요. 먼저 원하는 동작을 테스트로 적고, 아직 구현이 없어 실패하는지 확인해요. 그다음 테스트를 통과하도록 코드를 만들고 동작을 유지하며 정리해요. TDD는 Test-Driven Development, 테스트 주도 개발을 뜻해요.
이런 상황에서 만나요
신청 인원은 1명 이상이어야 한다는 규칙을 추가하려는 상황이에요. AI에게 “0명 신청을 거절하는 검사를 먼저 작성하고 실패를 확인한 뒤 구현해 줘”라고 요청할 수 있어요.
원하는 규칙을 먼저 검사로 적어요
규칙: 0명 신청 거절
현재 결과: 신청 허용 → 검사 실패
0명 신청을 거절하도록 수정
같은 검사 다시 실행 → 통과
중복 코드 정리
관련 검사 다시 실행 → 통과 유지
- 1기능이 아직 없어서 실패하는지 확인해요.
- 2기대값을 바꾸는 대신 동작이 규칙에 맞도록 구현해요.
- 3읽기 쉽게 고친 뒤에도 동작을 다시 확인해요.
처음 실패한 이유가 검사 환경의 오류인지, 아직 기능이 없기 때문인지 확인하세요. 구현 뒤에는 새 검사와 관련된 기존 검사도 실행해요. 요구한 규칙은 바뀌지 않았는데 통과시키려고 기대값만 바꾸지는 않았는지 살펴보세요.
헷갈리기 쉬운 점
코드 작성 후 테스트를 추가해도 TDD인가요?
그것도 유용한 테스트지만 순서는 달라요. TDD에서는 원하는 동작을 검사로 먼저 표현하고 실패를 확인한 다음 구현을 진행해요. 테스트 파일이 있다는 사실만으로 TDD를 했다고 보지는 않아요.
요구사항이 틀리거나 빠져 있으면 테스트도 잘못된 목표를 검사할 수 있어요. 무엇이 올바른 동작인지 먼저 합의하고, 아주 작은 구현 세부사항보다 사용자에게 필요한 규칙을 기준으로 잡아요.
왜 알아야 할까요?
AI에게 요청할 동작을 검증 가능한 조건으로 바꿀 수 있어요. 구현과 테스트가 서로 다른 요구를 따르거나, 결과만 보고 정답을 바꾸는 일을 줄이는 데 도움이 돼요.
조금 더 자세히
실패하는 검사 작성, 통과하는 구현, 동작을 유지한 코드 정리를 흔히 Red–Green–Refactor라고 부릅니다. 코드를 정리하는 단계에서도 검사를 다시 실행해 원래 동작이 유지되는지 확인합니다.
작은 규칙을 짧은 주기로 구현할 때 적용할 수 있습니다. 화면 디자인 탐색이나 외부 서비스 연결처럼 다른 검증이 필요한 부분도 있으므로 모든 품질 확인을 이 과정 하나로 대신하지는 않습니다.
직접 사용할 때 확인해 보세요
- 원하는 동작과 검사 조건을 먼저 정한다
- 기능이 없어서 실패하는지 확인한다
- 구현과 코드 정리 후에도 검사를 실행한다
관계 지도
