1. 문제점?
가끔 테스트 작성에 너무 과하게 집착하게 되면, 본래 목적을 잃어버리게 되는 경우가 있다
즉, 하나의 기능을 구현 하는데만 온 신경이 쏠리는 것이다
하지만 소프트웨어 관점에서 볼 때, 이는 그리 중요하지 않거나 원하는 방향이 아닐 경우가 있다
꼭 필요한 테스트를 빼먹을 수도, 굳이 테스트의 필요가 없는 부분까지 작성할 수도 있다
이는 모두 목표가 없이 작성을 해서 그렇다
달성 목표가 명확하지 않다!
뭘 어떻게 구현해야 할지는 알고 있으나, 테스트 작성은 개인마다 다르기에 달성 목표도 다를 수 밖에 없다
그리고 개발자에게만 맡겨버리니, 정작 사용자 관점에서 필요한 부분은 빠질 수가 있다
이것을 해결하기 위해선, 공통된 목표를 만들어야 한다
개발자가 아닌 사람들도 모두가 끄덕거릴 수 있는 달성 목표가 있으면 해결된다
2. BDD - 목표를 만들자!
BDD란 Behavior Diriven Development의 약자로, Behavior 즉 사용자 행위를 목표로 하고 개발을 진행하는 방식이다
당연한거 아니야? 개발은 사용자의 니즈에 맞춰져야지! 라고 할 수 있겠지만,
협의없이 혼자 진행하다보면 딴 길로 새는 것은 당연하다
그렇다면 이것은 어떻게 진행하면 될까?
이것도 역시 3단계 프로세스가 존재한다
Use Case 생각해보기
사용자 관점에서 행위를 정해본다. 이 과정은 반드시 모두와 협의를 하여야 한다
혼자서 고민하고 생각한다면 그건 위에서 말한 문제점을 반복하는 행위이다
모두와 협의해야 떠오른 케이스가 꼭 생각해야 할만큼 중요한건지, 혹은 빠진게 없는지 등
혼자서는 몰랐던 여러 부분을 채울 수 있다
이 단계도 역시 Use Case 다이어그램 등을 그려 정리해보는 것이 좋다
Test 형식에 맞게 구체화
그림이나 글로 표현한 것을 Test 작성을 위한 형식으로 변경하는 단계이다
우리가 흔히 작성하는 Given - When - Then이 바로 그것이다
- 가정이 주어지고(Given)
- 원하는 부분을 수행하면(When)
- 원하는 결과가 나와야 한다(Then)
작성 예시는 다음과 같다
기간이 만료된 모집공고에(Given)
지원하면(When),
마감된 공고란 에러가 발생한다(Then)
Test 개발 진행
작성된 테스트 케이스를 가지고 개발을 진행하면 된다
이 부분 부터는 이전의 TDD와 동일하다
3. DCI?
DCI는 Describe - Context - It의 약자이다
도대체 뭘 설명한다는 것이며, Context란 뭔 뜻일까?
1. Given - When - Then의 단점
Given - When - Then은 주어진 상황/행동을 설명하며 풀어내는 방식, 즉 상황에 초점이 맞춰져있다
그렇다보니 하나의 기능에 대한 테스트가 많아질수록 설명이 장황해지면서 관리하기가 매우 까다롭게 된다
- 블로그 글쓴이는 자신의 글을 수정할 수 있다
- 블로그 글쓴이는 자신의 글에 달린 댓글을 신고할 수 있다
- 블로그 글쓴이는 자신의 글에 달린 댓글을 삭제할 수 있다
- 블로그 글쓴이는 자신의 글에 달린 댓글을 수정할 수 없다
. . .
결국은 댓글의 수정 / 삭제 / 신고 여부와 내 글을 수정 가능한지가 중요한데,
상황을 풀어서 설명을 하니 복잡할 뿐더러 테스트의 내용이 한눈에 들어오지 않는다
DCI는 이를 해결하기 위해 뭘 하는지, 즉 행동(It)에 집중한다
그 앞의 상황은 계층 구조로 깔끔히 정리하고, "넌 이걸 테스트하는게 목표야!"라는 것을 알기 쉽게 해준다
- 블로그 글쓴이는(Describe)
- 자신의 글을(Context)
- 수정할 수 있다(It)
- 내 글에 달린 댓글을(Context)
- 신고할 수 있다(It)
- 삭제할 수 있다(It)
- 수정할 수 없다(It)
위의 예시에서 알 수 있듯,
Describe는 누가(Who)에 해당하는 것으로, TDD의 대상을 설명한다
이 부분이 길어진다면 이 또한 계층적으로 작성할 수 있다
Context는 주어진 상황을 의미한다
남의 글인지, 내 글인지 등 상황을 설명하는 부분이다
이 방법의 메인인 It은 행동을 의미한다
그래서 원하는 결과는 무엇인지를 설명하는 부분이다
해당 방식은 누가 어떤 상황인지는 계층 구조로 잘 정리해놓았기에, 뭘 하는지를 한눈에 알아볼 수 있다
2. 항상 옳다?
그렇다고 DCI 방식이 항상 좋은 것은 아니다
같은 주체가 같은 상황에 일어나야 하는 일들이 많을 때 유용한 방법인 것이지,
상황 자체가 간단하다면 오히려 반대로 설명이 한줄에 들어오지 않아 보기 까다로울 수 있다
이 점을 생각하고 작성된 Use Case를 보고 잘 판단하여 둘 중 골라서 사용하면 된다
이제 TDD가 무엇인지 대략 알아보았다
다음에 알아볼 것은 DDD인데 이것은 굉장히 생각해야 할 것이 많고 까다로운 주제이다
전략적 설계, 전술적 설계, MSA 등 다뤄야 할 부분이 많으며, 필자도 최근에 정리하면서 깨달은 부분도 많다
조금 긴 여정이 될 것 같으니 잘 해보자!
