Introduction
프로젝트 진행중에는 TDD(Test-Driven Development)를 시간적 여유가 없었습니다.
TestCode를 이해하기 위해, Test code의 목적과, 어떤 종류가 있는지 공부해보도록 하겠습니다.
[목차]
- 테스트란?
- 테스트의 종류
- 각 종류에 대한 이해
- Test code 직접 작성해보기
Test 란
테스트의 정의를 국어사전에 쳐보았습니다.
"컴퓨터 본체, 주변 장치, 부품 등의 하드웨어나 소프트웨어를 작동시켜 보고, 동작 도중과 최종 상태가 미리 상정된 상태와 비교해서 차이가 있는지의 유무를 조사 하는 것을 말한다."
요약하자면: 개발자가 만든 어플리케이션이 실제로 의도된대로, 작동하는지를 확인하는 것을 의미한다고 이해할 수 있습니다.
보통 프로젝트의 작업 순서를 보면,
기획-> 설계 -> 구현 -> 테스트 -> 배포 5가지 단계로 구성되어있습니다. 이 중 테스트에 대해 알아보겠습니다.
Test 란?
위에서도 알 수 있듯이, 개발자가 기능을 구현하고 제대로 작동하는지 확인하는 것을 Test라고 할 수 있습니다.
그렇다면 이 Test를 통해 얻을 수 있는 것들이 무엇이 있을까요?
Test Code의 장점
개인적인 생각으로는 가장 큰 장점은, 협업을 하는 과정에 있어서, 함수의 Spec을 검증하는 용도로 사용할 수 있다고 생각합니다.
우리가 어떤 프로젝트에서든, 함수를 만들면, 그 함수는 누군가에 의해 사용될 수 있음을 인지해야 합니다.(*중요)
함수를 만드는 이유는 중복의 제거와 유지보수의 이점을 얻기 위해서란 것을 잊으면 안됩니다.
이렇게 만든 함수의 스펙을 Test Code를 통해 작동하는 것을 확인할 수 있게 만들어 놓는다면, 사용하는 사람의 입장에서, 의도를 더 분명히 알 수 있겠지요..
(물론 함수명, Parameter 변수명 .. 등등 을 통해서도 충분히 이해가 가능하게 만드는것이 더 중요합니다.)
여기까지는 저 개인의 생각이고.. 이후에는 여러 블로그의 내용들을 취합한 내용입니다.
- 개발 과정 중 예상치 못한 문제를 미리 발견 할 수 있다. (Client 보다 빠르게 확인가능 )
- 작성한 코드가 의도한 대로 작동하는지 검증할 수 있다.
- 코드 변경에 대한 사이드 이펙트를 줄이는 예방책 이다.
- 코드 변경 시, 변경 부분으로 인한 영향도를 파악할 수 있다.
- 코드 리팩토링 시 기능 구현이 동일하게 되었다는 판단을 내릴 수 있다.
여러가지 장점들을 보았는데 가장 와닿는 부분은..
"개발 과정 중 예상치 못한 문제를 미리 발견할 수 있다"는 부분인거 같습니다.
Test Code를 작성하면.. 실제로 어떻게 Test해야할지 고민하면서, 로직에 대해 다시 한번 생각하는 계기가 있기 때문에, Code를 올바르게 짤 수 있다고 생각합니다.
(물론 그 만큼 시간이 초기 개발 시간이 많이 드는거 같습니다.)
#cf) TDD에 대해 간단하게 읽어보았는데.. 실제로 TDD가 효과적인 방법인가에 대해서는 아직은 잘 모르겠습니다. (테스트를 많이 해야한다는 것에는 동의합니다만.. 조금더 공부하면 알아갈 수 있을거라 생각합니다.)
Test에 대해 조사해보면서, 많은 종류의 Test들이 있다는 것을 알게 되었습니다. 각각 어떤 종류가 있는지 알아보겠습니다.
Test code 의 종류
테스트 코드의 종류에는 크게 3가지로 분류 할 수 있습니다.
- 단위테스트
- 통합테스트
- UI 테스트
각 종류별로, 어떠한 개념인지 알아보도록 하겠습니다.
1. 단위 테스트
제가 분류한 3가지 테스트들 중 가장 작은 단위로, 클래스에 포함되는 함수들의 기능에 대한 유효성을 검증하는 테스트입니다. 단위테스트로부터, 통합테스트, 인수테스트까지 나아가게 하는 기초가 되는 테스트라고 생각합니다.
저는 백엔드 서버를 주로 Spring 을 활용하여 개발을 하고 있습니다. Spring Framework를 사용하게 되면 자연스럽게 3layer ( controller , service ,repository)의 구조로 개발을 하게 됩니다. 이 때, 단위테스트를 각 layer별로 진행해 볼 수 있겠습니다.
예를들어 service layer class들의 함수의 비지니스 로직들을 하나의 작은 단위로 두고, 단위 테스트 코드를 짜볼 수 있습니다.
(이 때, repository가 반드시 포함하게 되는데, 이 때, mocking을 통해 가짜 개체인 repository를 활용하여 servicel layer의 비지니스 로직만을 체크하면 되겠습니다.)
개인적으로 테스트코드를 짜면서 느낀것은, Test code를 짤 시간이 부족하거나, 비지니스 로직이 자주 바뀐다면, 테스트코드를 짜기로 생각했으면, 최소한 어플리케이션의 핵심 비지니스 로직만이라도 만들어놔야 한다 생각합니다. 간단한 것들은, 테스트코드의 의미가 퇴색되는 느낌을 많이 받았습니다.
2. 통합 테스트
통합테스트는 개발자가 만들 프로그램이 전체적으로 잘 작동하는지, 작동의 관점에서 테스트하는것을 생각하면 됩니다. 단위테스트와 다르게 DB에 접근하던지, 어플리케이션에서 외부 API call을 한다면, 실제로 외부 api call과 응답을 통해 비지니스 로직이 실제로 작동하는지 확인하는 테스트 입니다.
예를들어, springboot를 통해 api 를 개발했다면, 단위테스트와 다르게 springboot를 띄우고 bean을 등록한 후에, api call 을 시작해서 작동하는것까지 한번에 다 체크하는 것이라 할 수 있겠습니다.
실제로, product를 받아보는 사람 입장에서는 통합테스트가 더 중요하다고 생각하시는것 같습니다.
( 실제로 내부가 어떻게 됬든 일단 작동하는지를 원하기 때문인가..
저는 굳이 중요한것을 따지자면, 단위테스트가 더 중요하다고 생각합니다.. 단위 테스트가 모여서, 통합테스트가 되기 때문입니다. 근본이 중요하다.)
3. UI 테스트
UI Test의 개념은, 실제 어플리케이션을 사용하는 사용자의 흐름에 대해 테스트 함으로써, ui변경 사항으로인해 발생할 수 있는 문제를 사전에 차단하기 위한 테스트입니다. (통합보다 더 큰 개념으로, 사용자가 사용하는 화면에서의 검증이라고 생각하면 될거 같습니다.)
(지금 개발하고 있는 것이 api 서버 이므로.. 지금 당장은 이해하기 어려울 거 같습니다.. 나중에 프론트도 공부하게 되면 하는일이 생기겠지..)
여기까지 테스트가 무엇이고, 왜하는지, 종류가 어떤것들이 있는지 알아보았습니다. 다음 글에서는, 직접 테스트해본 code들을 들고와서 어떤것들을 사용하였고 어떤점이 중요한 점인지 생각을 작성해보도록 하겠습니다~
Reference
