[CS] 소프트웨어 테스트와 TDD
소프트웨어 테스트 ?
소프트웨어 테스트란 소프트웨어가 의도한대로 동작하는지를 테스트하는 행위입니다. 옛날에는 테스트팀이 별도로 존재하며, 개발자는 테스팅 과정에 큰 관여를 하지 않았지만, 최근에는 개발자가 자동화 할 수 있는 소프트웨어 테스트를 구현하고 실행하는 것이 보편화되고 있습니다.
자동화된 테스트란 사람이 손수 테스트하는 것이 아닌 컴퓨터를 통해서 소프트웨어를 테스트하는 것을 의미합니다. 소프트웨어를 통해서 테스트를 할 경우 아래와 같은 이점을 얻을 수 있습니다.
- 컴퓨터를 통해서 실행하기에 사람이 실행하는 것보다 빠르다.
- 정해진 스크립트에 따라 일관성있게 동작하기에 사람이 테스트 할 경우 발생할 수 있는 휴먼에러를 기피할 수 있다.
개발자가 소프트웨어 테스트를 작성할 경우 얻을 수 있는 가장 큰 이점은 "피드백을 빠른 주기로 개발 중에 받을 수 있다"입니다. 거의 실시간으로 소프트웨어의 동작에 대해서 피드백을 받으며 올바른 방향으로 수정해나갈 수 있고 소프트웨어가 최소한 작성한 테스트 코드 안에서 제대로 동작한다는 확신을 가질 수 있게 됩니다. 이는 곧 개발자의 생산성 향상을 야기합니다. 그리고 자동화된 테스트는 추후 CI/CD와 같은 프로세스에서도 해당 소스코드들이 정상적으로 동작하는지 확인하는 과정에서 사용할 수 있는 등 다방면으로 활용할 수 있습니다.
소프트웨어 테스트의 종류
1) Unit Test
유닛 테스트는 테스트중에서 가장 로우 레벨, 가장 작은 범위를 테스트합니다. 유닛 테스트는 개별 함수, 메서드, 클래스, 컴포넌트 등의 동작을 테스트합니다. 유닛 테스트는 제일 간단한 형태의 테스트로 실행하는데 가장 적은 비용이 듭니다. 따라서 유닛 테스트는 개발 과정에서 가장 빈번하게 수행할 수 있는 테스트입니다.
2) Integration Test
통합 테스트는 두개 이상의 모듈을 결합해서 동작을 잘 수행하는지에 대한 테스트입니다. 예를들어 컴포넌트 안에서 렌더링이 정상적으로 되는지만 테스트한다면 이는 개별 컴포넌트에 대한 유닛 테스트 이지만, 이 컴포넌트가 Redux등의 상태관리 라이브러리와 통합했을 때 두 모듈이 잘 어우러져서 최종적으로 의도한 결과를 도출하는지 테스트하는 것을 통합 테스트라고 할 수 있습니다. 통합 테스트는 여러 모듈들을 통합하는 과정이 필요하기에 유닛 테스트보다는 많은 비용이 드는 테스트라고 할 수 있습니다.
3) E2E Test(End-to-End Test)
E2E 테스트는 실제 유저가 어플리케이션을 사용하는 것과 유사한 환경을 구축한 후 실제 유저의 동작을 흉내내서 테스트하는 것입니다. 이는 실제 유저의 동작 흐름을 그대로 모방해서 테스트할 수 있다는 장점이 있지만 환경을 구축해야 하며, 유저의 행동 시나리오를 구축해야 하기에 굉장히 비싼 테스트입니다. 대부분 핵심 기능에 대해서 E2E 테스트를 구축 한 후 확인이 필요한 순간에만 실행하는 것이 일반적입니다.
TDD란?
TDD는 Test-Driven-Development의 약어로서 소프트웨어를 개발하는 여러 방법론 중 하나입니다.
TDD의 핵심은 기존에는 테스트 코드를 먼저 작성하고, 그 후에 실제 코드를 작성하는 것입니다. 일반적인 개발 흐름은 코드작성 → 테스트코드 작성의 흐름을 따르지만, TDD는 실제 코드를 작성하기도 전에 테스트 코드부터 작성을 시작합니다.
TDD는 크게 Red-Green-Blue 3가지 단계를 거칩니다.
- Red: 실제 구현을 하기 전에, 먼저 실패하는 테스트 코드를 작성한다. 그 후 테스트를 실행한다. 실제 코드가 작성되지 않았기에 테스트 코드는 당연히 실패한다.
- Green: 테스트를 통과하기 위해 가장 간단한 형태로 코드를 작성한다. 그 후 테스트를 실행한다. 테스트는 실제 구현이 되었기에 통과한다.
- Blue: Green 단계의 코드를 더 좋은 형태로 리팩터링한다. 이 과정에서 지속적으로 테스트를 실행해서 테스트가 통과하는지 확인한다.
이러한 방식으로 개발을 하게 되면 아래와 같은 이점을 얻을 수 있습니다.
- 코드 작성 과정에서 확신 및 자신감을 얻을 수 있게 된다.
- 코드의 동작에 대한 테스트가 작성되어 있으며 이를 충족하는 것을 실시간으로 피드백 받으며 진행하기에 코드가 제대로 동작할것이란 확신을 얻을 수 있다.
- 구현을 잘못 한 경우 바로 확인할 수 있다.
- 실제 개발을 하다보면 한참 코드를 작성했는데 실제 브라우저에서 테스트했을 때 원하는 대로 동작하지 않아 어느 지점부터 잘못됬는지 파악하기 위해서 전체 개발과정을 돌아봐야 하는 경우는 꽤나 자주 발생하는 상황입니다, 하지만 테스트 코드가 준비된 상황에서 개발을 하게 되면 특정 지점에서 잘못된 동작이 발생하면 바로 알 수 있기에 바로 구현을 수정할 수 있습니다. 즉 디버깅 과정이 용이해진다는 장점이 있습니다.
- 코드의 동작이 명확해진다.
- “어떻게 코드를 짜야할 지가 아닌 무슨 코드를 짜야할 지 부터 고민하게 된다.”
- 테스트 코드를 작성하기 위해서는 이 코드가 어떤식으로 동작해야하는지를 먼저 생각해야합니다. 기존의 방식대로 일단 코드부터 작성하게 되면 나중에 이 코드에서 하고자하는 역할과, 구현해야 되는 동작들이 뒤죽박죽 섞이게 되는 상황이 발생할 수 있지만. 테스트 코드를 미리 작성한다면 이 과정에서 자연스럽게 이 코드가 해야하는 동작과 어떤 인터페이스가 갖춰줘야하는지를 생각하고 표현하게되므로 자연스럽게 코드의 동작과 관심사의 분리가 비교적 잘 이루어진다는 장점이 있습니다.
출처 : 원티드 프론트엔드 프리온보딩 인턴쉽