테스트 주도 개발

1. 개요[편집]

---

전통적인 공학론적 개발 프로세스는 사전에 철저히 검증된 계획 하에 장기간에 걸쳐 많은 인원과 비용을 투입하여 목표를 완수하는 방식을 따른다. 소프트웨어 개발 역시 초기에는 이러한 프로세스에 따라 폭포수 모델 등을 따랐으나, 구현하게 될 소프트웨어의 규모가 커지고 복잡해짐에 따라 소프트웨어 위기(Software crisis)라는 문제에 봉착하게 되고, 소프트웨어 공학에서는 소프트웨어 개발 과정이 다른 공학적 방식과 큰 차이가 있음을 인지하게 된다.

소프트웨어는 유동적이고 예측하기 어렵다. 또한 소프트웨어가 발전하면서 점차 확장가능성, 개방적 구조를 요구하게 되었다. 따라서 구체적으로 개발이 언제 완료될 것인지 예측하는 것이 매우 어려울 뿐더러, 인원과 비용을 늘린다고 해서 개발 시간의 절감이나 질적인 성과를 보장할 수 없다. 소프트웨어의 규모가 커지고 복잡해질수록 기존의 폭포수 모델을 적용했을 때 다음과 같이 다양한 문제점이 발견되었다.

1. 개발에 적용할 수 있을 수준의 구체적인 요구사항을 작성하는 것이 매우 어려움. 불가능함.
2. 규모가 커질수록 설계에 요구되는 시간과 비용이 기하급수적으로 증대됨.
3. 실제로 개발에 들어가고나서 정해진 요구사항이 변경되거나, 다양한 문제점이 발견됨.
4. 위와 같은 문제로 인해 작업 난이도 및 개발일정을 예측하는 것이 어려움.

기존의 계획주도 개발방식에서는 세운 계획대로 개발이 흘러가지 않으며, 그것을 보완하기 위해 언제나 개발이 지연되었고, 개발자에게 주어지는 스트레스와 과중한 업무, 그 결과 떨어지는 생산성과 상품성 등에 직면하여 소프트웨어 공학자들은 전통적인 개발 프로세스에 큰 의문을 제기하였다. 이에 완전한 설계를 지향하는 폭포수 모델을 폐기하고, 초기의 설계 비용을 줄이고자 작은 규모의 소프트웨어를 완성한 다음 그것을 점차 보완해가며 복잡한 소프트웨어를 완성하는 나선형 모델(Spiral model)을 도입하는 등 산업에서는 보다 경험적 프로세스 제어 모델로 이행하게 된다.

애자일 프로그래밍(Agile programming) 방식은 계획과 문서에 의존하는 기존의 방식을 부정한다. 미래에 대한 예측을 차단하고 지속적인 프로토타입의 완성을 반복하여 그때그때 소단위 요구사항을 추가하고 기존의 문제점을 해결하여 점차 큰 규모의 소프트웨어를 완성하는 개발 방식이다. 익스트림 프로그래밍(eXtream Programming, XP)은 대표적인 애자일 프로그래밍 개발방법론 중 하나로, 고객이 원하는 소프트웨어를 빠른 시간 내에(약 2주) 프로토타입의 형태로 전달하고 이를 통해 고객이 원하는 소프트웨어를 이끌어내며, 수시로 발생하는 요구사항에 대처하는 것을 목표로 한다.

다른 애자일 방법론과 구별되는 XP의 특징은 테스팅이다. 구현과 테스트를 하나의 쌍으로 취급하여, 실제 구현과 동시에 테스트 코드를 작성하도록 하며, 이것에 기반한 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"를 실천하는데에 큰 도움을 줄 수 있다. 왜냐하면 매번 프로토 타입을 고객에 전달함에 있어서 프로토 타입 자체로써 버그가 상대적으로 적은 완벽에 가까운 데모를 경험하게 해줄 수 있기 때문이다.

테스트 주도 개발(Test Driven Development, TDD)은 익스트림 프로그래밍 개발방법론의 실천 방안 중 하나이다. 개발이 이루어진 다음 그것이 계획대로 잘 완성되었는지 테스트 케이스를 작성하고 테스트하는 타 방식과는 달리, 테스트 케이스를 먼저 작성한 다음 테스트 케이스에 맞추어 실제 개발 단계로 이행하는 개발방법론을 말한다. 묵시적으로 잠재된 상황을 가정하지 않고 테스트 케이스만을 완벽하게 수행하는 것을 목표로 하기 때문에 매우 빠르게 목표를 완료할 수 있다. 한편, TDD 자체가 하나의 테스트가 완전하지 않다는 것을 가정하고 있기 때문에 1차 테스트를 완료한 다음에 새로운 테스트 케이스를 확장해서 작성하고 그것을 통과하기 위한 개발에 들어가는 과정을 끊임없이 반복하여 큰 규모의 프로젝트를 완성해가는 것이다.

2. 분류[편집]

---

테스트 주도 개발에서 작성되는 테스트는 단위 테스트가 대표적이다. 먼저 단위 테스트는 말 그대로 한 단위[1]만을 테스트하는 것이다. 단위 테스트를 작성하려면, 일단 테스트를 작성한 뒤 컴파일 에러가 일어나지 않도록 테스트에서 쓰이는 클래스와 그 메소드의 스텁을 만들어 둔다. 테스트가 실패하는 것을 확인하고(= 컴파일 에러는 없는 것을 확인하고) 클래스를 구현한다. 클래스에서 필요한 다른 클래스가 필요하면 일단 스텁으로 지금 작성중인 클래스의 테스트를 통과하게만 해 두고, 나중에 그 클래스의 테스트 케이스를 작성한 후 구현한다. 이런 식으로 프로젝트 전체를 완성해 나간다. 하지만 단위 테스트는 단위 하나하나에 대해서만 검증할 수 있으므로, 이를 해결하기 위해 인수 테스트를 작성한다. 사실 인수 테스트는 전통적으로 사람(QA)의 영역이었지만, 코드로도 약간 구현해두면 품질에 큰 도움이 된다[2].

3. 장점[편집]

---

• 코드의 유지보수가 용이해진다

• 프로그래밍 시간이 단축된다

• 뛰어난 프로그램 소스코드 기록

4. 단점[편집]

---

• 인간은 실수를 미리 인지하지 못한다

• 변경되는 비즈니스 로직에 대응하지 못한다

• 추가적인 기록물의 증가

5. Unit Testing 프레임워크[편집]

---

• xUnit

• Jest

6. Code Coverage[편집]

---

테스트가 실제로 거쳐가는 코드가 몇 줄인지 확인하는 용도로 쓴다. 예외 처리 같은 것이 제대로 테스팅 되는지 확인하거나, 아니면 다른 개발자들이 제대로 테스팅 코드를 작성하는지 확인하려면 쓰는 것이 좋다. 프로파일러처럼 사실 유닛 테스트와는 독립적으로 동작한다. 그래서 본인이 어떤 코드를 써 놓고 코드가 어떻게 흘러 가는지 파악하는 데 사용할 수도 있다.

다만, 각종 프로파일러나 벤치마크 툴을 돌릴 때, 자체적으로 잡아먹는 성능 때문에 실제보다 성능이 낮게 측정되는 현상처럼, Coverage를 적용시키고 나면 테스트 속도가 느려질 수 있으므로 대형 프로젝트에서는 신중히 적용하자.

• JaCoCo

7. CI[편집]

---

위와 같은 프레임워크들을 활용해서 테스팅 케이스를 작성하고 나면 직접 돌려 보아야 하는데, 사람이 일일이 수동적으로 돌리려면 노동력이 들어가게 되고, 자동으로 돌린다 할지라도 서버를 구매할 여력이 되지 않는다면 클라우드 서버를 빌려야 한다.
보통 특별히 클라우드 서버를 빌려 쓰기 보다 CI를 사용하는 편이다.
개인 사용자나 오픈 소스 프로젝트의 경우 아예 무료로 쓸 수 있게 해주는 경우가 많으므로 잘 찾아보고 공부해 보도록 하자.

• Travis CI
• Azure Pipelines
• CircleCI
• 등등