테스트 코드 (Test Code)란?

이번 프로젝트에서 TDD 방법론으로 개발을 진행하기로 결정하였다.

 

🤔 TDD란? 

TDD는 (Test-Driven-Developmetnt) 테스트-주도-개발이란 뜻.
 소프트웨어 개발 프로세스에서 테스트를 먼저 작성하고, 그 테스트를 통과하는 코드를 나중에 작성하는 방법

 

🚦구현을 한 이후에 잘 돌아가나 테스트를 하는 게 맞는 순서 아닌가?라는 생각이 들었다.
   우선, 테스트 코드부터 확실히 인지한 이후, 다시 판단해보자!

 

RESTful API를 알려면, API를 알아야 되듯이, TDD를 알려면 당연히 Test Code부터 알아야 된다.

 

테스트 코드에 대해 알아보자!

 

테스트란? (Testing)

 

직관적으로 테스트는 말 그대로 검증하는 것이다. 그렇다면 소프트웨어에서의 테스트는 무엇을 검증하는 걸까?

소프트웨어 테스트는 프로그램이 의도한 대로 정확하게 작동하는지 확인하는 과정입니다.
이는 버그를 찾아내고, 소프트웨어의 품질을 보장하며, 사용자의 요구사항을 충족시키는지 검증하는 것을 포함한다.

 

구현 코드가 있다면 , 그거에 상응하는 테스트 코드가 있고 서로 상호작용하며 순환하는 과정을 통해 

코드의 품질과 신뢰성을 지속적으로 개선하는 것이다.

 

 

즉, 테스트 코드는 구현 코드의 품질과 정확성을 검증하여 피드백을 제공하고, 이를 바탕으로 구현 코드는 리팩토링을 거쳐 개선된다.
이러한 과정이 반복되면서 코드의 품질이 지속적으로 향상되는 순환적 구조를 형성한다.

 

---

🤔 그렇다면 둘 중 무엇이 먼저일까? 

 

결론부터 말하면 정답은 없다. 우리 프로젝트에서 진행하려 하는 TDD(테스트 주도 개발) 방법론 또한 말 그대로 방법론이기 때문에
프로젝트의 성격, 팀의 경험, 개발 환경 등 다양한 요소에 따라 적용 여부와 방식이 달라질 수 있다.

 

테스트 개발 방법론의 종류

 

이렇게 여러 장단점이 공존하는 만큼 각자의 상황에 테스트 개발 방법론을 유연하게 선택하는 것이 중요하다고 생각한다

 

---

🤔 그렇다면 테스트의 범위는 어떻게 설정해야 할까?

 

테스트의 유형

수학문제를 풀어볼 때 검산을 한다고 생각해 보자.

 

단순연산이 맞는지만, 또는 한 과정 자체가 맞는 지만, 또 어떨 때는 전체 검산을 다시 해볼 때가 있다.

이처럼 테스트 코드에도 범위가 존재한다.

 

 

크게 단위 테스트, 통합 테스트, 기능 테스트  셋으로 분류된다.

 

우선 지금은 자세한 내용을 다루는 것이 아닌 큰 개념을 가져가기 위함이므로 표로 직관적으로 보는 것이 제일 깔끔하다 생각했다.

 

 

 

단위 테스트:

• 개발자가 직접 작성하고 실행하는 경우가 많다.
• 자동화된 테스트 프레임워크를 사용하여 빠른 피드백 제공
    ✅ -JUnit (Java)  간단한 어노테이션을 통해 테스트를 작성하고, 코드 변경 시 테스트를 자동으로 실행할 수 있다.
• 코드 변경 시 기존 기능에 문제가 생기는지 빠르게 확인할 수 있음

통합 테스트:

• 단위 테스트보다 더 넓은 범위를 다루며, 여러 컴포넌트 간의 상호작용 검증
• 데이터베이스, 파일 시스템, 네트워크 등 외부 의존성을 포함할 수 있음
• 실제 운영 환경과 유사한 조건에서 테스트 수행

기능 테스트:

• 사용자 시나리오를 기반으로 테스트 케이스 작성
• UI 테스트를 포함할 수 있으며, 종종 자동화 도구 사용
• 비기능적 요구사항(성능, 보안 등)도 이 단계에서 테스트될 수 있음

---

 

결론적으로, 단위 테스트는 개발 과정에서 가장 기본적이고 핵심적인 테스트 방법이다.

TDD 또한 단위 테스트가 기반이 될 거라 판단된다.

단위 테스트에 집중하여 기초를 다진 이후, 그 이후 통합테스트, 기능 테스트의 프로세스까지 넘어갈 수 있도록 노력해야겠다.

다음번엔 직접 테스트 코드를 작성하며 조금 더 깊은 고찰을 하는 시간을 가져보자!

단위 테스트는 빠른 실행과 즉각적인 피드백, 그리고 세밀한 오류 감지 능력 덕분에  실무에서 가장 널리 활용되며,
전체 테스트 전략의 본질이라 생각한다.

---

🙇‍♂️ 결론

사실 '결론'이라고 적긴 했지만, 아직 결론을 내릴 수 없는 상태이다.
그 이유는 TDD를 실제로 적용해본 경험이 없기 때문이다.

하지만 현재로서의 개인적인 생각으로는 TDD(테스트 주도 개발)의 필요성을 크게 느끼지 못하고 있다.
TDD는 주객이 전도된 듯한 느낌을 준다.

이러한 인상을 받는 주된 이유는 다음과 같다:

1. 현재 나의 실력 수준을 고려했을 때, 기능 구현 자체가 우선순위라고 생각한다.
2. TDD를 제대로 적용하려면 상당한 시간과 노력이 필요할 것으로 보인다.

그렇다면 "충분한 시간이 주어진다면 TDD를 완전히 소화할 수 있겠느냐?"라는 질문에 대해서도, 솔직히 긍정적인 대답을 하기 어렵다.
그만큼의 훈련과 경험이 부족하기 때문이다.

다만, 이는 현재 시점에서의 견해일 뿐이며, 앞으로 실제 프로젝트에 TDD를 적용해보면서 이러한 생각이 변할 수 있다는 점은 열어두고 있다. TDD가 코드의 품질과 유지보수성을 높인다는 장점에 대해서는 알고 있지만, 현재로서는 그 이점을 체감하기 어려운 상황이다.

현 시점에서는 테스트 지원 개발 방법이 조금 더 효과적인 방법으로 판단된다.

특히, 단기 프로젝트인 이번 프로젝트에서는 TDD 방법론을 적용하는 것이 적절한지 팀원들과 다시 논의할 필요가 있다고 생각한다.

실무자의 조언대로, 회사에서는 상황이 다르다. 회사의 요구에 따라 개발을 수행하는 것이 당연하다고 생각한다.
이것이 수동적인 자세로 보일 수 있겠지만, 냉철하게 생각해 보면 타당한 접근이다.

예를 들어, 회사가 '안정성'을 최우선으로 요구하는지, 또는 '빠른 개발 속도'가 중요한지 판단한 후
그에 맞게 유연하게 대응하는 것이 중요해 보인다.

향후 계획은 다음과 같다.

1. TDD를 포함한 다양한 개발 방법론을 지속적으로 학습하고 실험하며, 나의 기술을 향상할 계획이다.
2. 주체적으로 다양한 기술과 방법들에 대해 항상 열려있는 자세로 학습할 것이다.
3. 프로젝트의 성격과 팀의 요구사항에 맞춰 가장 적절한 개발 방법을 유연하게 선택하는 능력을 기를 것이다.
4. 어떤 방법론이나 기술이든 맹목적으로 따르지 않고, 항상 그 효과와 효율성을 비판적으로 평가하여 상황에 맞는 최적의 개발 방식을 선택할 수 있는 실력과 안목을 갖춘 개발자가 되도록 노력하겠다.