[개발 설계] ATDD(Acceptance Test-Driven Development)란? 그리고 TDD에 대한 생각

이번 시간에는 ATDD에 대해서 공부해 보려 합니다.

ATDD는 사용자 요구를 더 잘 이해하기 위한 방안으로 탄생한 소프트웨어 개발론 인데요, 현재 TDD에 대해서 공부하고 있는 저로써 TDD의 심도있는 이해에 도움이 될 것 같아 공부해 보게 되었습니다.

❓ATDD란?

ATDD는 TDD에서 한 발 더 나아간 개념이라고 할 수 있는데요, ATDD는 인수 테스트-주도-개발 이란 뜻인데요, 여기서 인수는 ‘인수인계’에서 뜻하는 그 인수라는 점에서 ATDD가 ‘소통’에 집중된 소프트웨어 개발 방법론이라는 것을 알 수 있습니다.

개인적으로는 이 그림이 ATDD의 핵심을 말해준다고 생각합니다.

❓ATDD의 장점?

ATDD는 각 팀 별로 요구사항을 이해하고 있더라도, 그 이해가 다를 수 있다는 관점에서 사용자의 요구사항을 명확하게 인지하고자 탄생한 개념인데요, 이러한 이유 때문에 다음과 같은 장점을 가집니다.

1. 배포 없이 대부분의 기능 동작을 테스트 할 수 있어 빠른 피드백을 받을 수 있다.
2. 새로운 팀의 도메인과 서비스 흐름 파악에 큰 도움
3. 요구사항을 명확하게 하기 때문에 문제를 초기에 발견할 수 있다.

사용자의 요구사항을 명확히 하여 빠른 피드백을 받을 수 있다는 것이 장점이라는 것이죠.

❓TDD와 ATDD의 차이점?

ATDD에 대해서 알아봤는데요, 그렇다면 TDD와 차이점이 뭘까요? 결국 테스트 주도 개발이란 점에서 같은 개념 아닐까요? 왜 ATDD란 개념이 새로 탄생한 것일까요?

이 둘의 차이점을 명확하게 개발 방법론으로 살펴봅시다.

TDD의 개발 방법은 다음과 같습니다.

ATDD는 다음과 같은데요,

팀 간의 이해를 명확히 하고, 그에 맞는 인수 조건을 정의하여 요구 사항을 철저히 충족할 수 있다는 것입니다.

❓ATDD 프로세스

위의 그림과 같이 ATDD 흐름이 이어지는데요, 이는 다음과 같은 프로세스를 통해 작성할 수 있습니다.

1. 사용자 스토리 (요구 사항 식별)
2. 인수 조건 작성When : 어떤 행동 또는 이벤트가 발생할 때를 정의합니다.
3. Then : 행동 또는 이벤트에 대한 결과를 정의합니다.
4. Given : 초기 상태를 나타내며 어떠한 조건에서 테스트를 수행할 것인지 정의합니다.
5. TDD 방법론으로 테스트 코드 작성

❗ATDD를 공부하고 생각 하는 테스트 주도 개발에 대해서

TDD라는 체계 자체가 ‘객체 지향’을 조금 더 ‘객체 지향’스럽게 만들어주는 설계의 방법론이라는 느낌을 받았습니다. TDD 설계 방법을 준수하면서 코드를 작성하면, 자연스레 SOLID 법칙을 준수하게 되고, 빠른 피드백을 통해 지속 가능한 아키텍처를 만들 수 있다는 느낌을 받았습니다.

그러나 이러한 방법론을 무조건 따랴야 할 필요는 없다는 생각이 들었습니다. 중요한 것은 이러한 방법론이 아니라, TDD에 대한 본질적인 목적을 이해함으로써 안정성 있고 효율적인 소프트웨어 개발을 해 나가는 것이 중요하다는 생각입니다. (그렇게 되면 자연스럽게 TDD의 방법론을 적용하게 될지도)