TIL 43 | Unit Test

임종성·2021년 8월 19일

TIL

목록 보기

15/22

1차 프로젝트를 통해 많은 경험을 하고 더 발전하기 위한 2차 프로젝트가 시작한지 벌써 3일이나 지났다. 새로운 팀원들과 같은 방식으로 협업하지만, 좀 더 효율적으로 코딩하기 위해 새로운 지식과 기술스택을 쌓는 것도 중요하다. 이번엔 Testing Pyramid라는 개념을 통해 시스템을 테스트하는 방식을 구분하고, Unit Test의 장점과 Develop Test의 원칙에 대해 알아보자.

지난 프로젝트에서는 내가 구현한 기능이 제대로 작동하는지 확인하기 위해 직접 POSTMAN을 통해 request를 받고 응답해주거나 프론트가 구현한 기능과 합쳐 직접 브라우저상에서 확인하는 테스트를 진행했다. 이런 방식은 사실 생각보다 비효율적이고, 시간이 많이 소요 될 수 있다.

그렇다면 개발자들이 사용한는 Test 에는 어떤 방식이 존재하고, Unit Test란 무엇일까?

Testing Pyramid

Testing Pyramid는 Google Test Automation Conference에서 제안된 테스트 피라미드로, 크게 시스템 테스트 방식을 3가지로 구분한다.

E2E(End-to-End) Testing / UI Testing

프론트와 백엔드가 통신해 테스트한것처럼, 직접 브라우저 상에서 값을 입력해 request에 적절한 response가 오는지 테스트하는 방법이다.
경험적으로도 프로젝트 후반부에 많이 사용된 Test 방식으로, 각자의 기능 구현이 완료되어야 실행이 가능하기 때문에 어렵고 까다롭다.
각자의 기능이 제대로 구현되었을 때는 실행이 가장 쉽다는 장점이 있지만 그만큼 비용이 많이 들고 실행 시간이 오래 걸리며 자동화 하기도 까다롭다.

Integration Testing

POSTMAN을 사용해 백엔드가 자체적으로 Test한 것처럼, 최소 두개 이상의 클래스나 서브 시스템의 결합을 Test하는 방식이다.
POSTMAN or HTTPie(Client) - Server(Django) - Model - Database
E2E Testing 다음으로 까다롭고 힘들다.

Unit Testing

Unit Test란, 내가 작성한 코드의 가장 작은 단위인 함수를 테스트 하는 방식이다.

E2E나 Interration Test와 다르게 사람이 Script로 한번에 자동으로 실행하는 방식이기 때문에 Test 비용이 싸다.
다른 Test와 비교해서 실행시간이 매우 빠르기 때문에 개발 및 배포 속도에 중요한 영향을 준다.
Unit Test를 잘 작성해 놓으면 장기적으로 유지보수가 쉽다는 장점이 있다.

Build Unit Test

내가 구현한 MenuPageView에 대해 Unit Test를 직접 작성해보자!

Unit Test Form

Django는 기본적으로 app을 생성할 경우 app directory 안에 tests.py를 만들어주고, django.test에서 TestCase, Client modeul을 제공해 Test Method와 가상 Client를 제공해준다.

Unit Test의 작성 frame은 기본적으로 다음과 같다.

class MenuPageTest(TestCase)
TestCase를 활용한 View Test Class 생성
def setUp(self)
Test용 Database에 Unit Test를 위해 필요한 DB Data 생성
def tearDown(self)
Test가 끝난 후 Unit Test를 위해 생성한 DB Data를 제거
Data 생성 역순으로 Table을 제거해야 한다.
def test_category_district_menu_get_view(self)
구현한 기능을 가능한 작은 단위로, 세분화하여 여러가지 경우의 수를 test하는 기능 작성
python3 manage.py test .
작성한 Unit Test를 이용해서 Test용 Database를 생성하고 Unit Test 실행

MenuPageView

내가 작성한 MenuPageView의 기능은 간단하게 설명하면 다음과 같다.

Client의 Filtering Request에 대해 등록한 공간(파티룸, 연습실 등) Data를 반환한다.
Filtering Case : Category(공간유형), District(지역), Count(인원수), Date(날짜)
Ordering Case : Like(좋아요), Price(가격 오름차순, 내림차순)
각 Case를 QueryParameter로 요청받아 Category 정보와 Space 정보 반환

Unit Test

Space Table이 District와 Category를 참조하고, Ordering의 경우에도 price와 like로 정렬되기 때문에 DB Data가 생각보다 많이 필요했다. 따라서 District와 Category를 각 4개씩 생성하고 총 16개의 Space를 만들었다.

Date로 Filtering하기 위해서 특정 Date에 예약이 꽉 찬 방이 존재해야 했기에 Order도 생성해주었다.
반복적으로 생성해주기 때문에 최대한 Test를 명확하게 하기 위해 Price, Like의 경우 abs를 사용해서 단순한 오름차순이나 내림차순이 아니게 되도록 했다.
Test Case는 총 3가지로,
- Category, District로 Filtering Test
- Category, Date, Count로 Filtering Test
- Price Desc Order Test
로 작성했다.