[T.Viewer 개발일기] 5. 단위 테스트를 합니다

Electron과 Vue, Vuetify로 만든 Cross Platform Tizen Log Viewer - T.Viewer 개발일기의 다섯번째는 단위 테스트!

개발 환경이 모두 갖춰져서 이제 즐겁게 개발을 시작하면 된다. 이번에는 TDD 개방 방식을 적극 사용하려 한다. 처음부터 끝까지 꼼꼼하게! with Unit Test!

왜 TDD인가

TDD는 Test-Driven Development를 뜻하며, 테스트 위주로 개발을 한다는 것이다. TDD 자체에 대한 설명은 생략하고, 내가 왜 TDD를 선택하게 되었는지에 대해서 짧게 적어본다.

간결한 코드를 구성하게 된다.

코드를 작성하기 전에 개발자는 요구사항이 이해해야 한다. 이해한 요구사항이 간단한 경우 별다른 어려움이나 이견없이 간단한 코드가 쉽게 도출이 된다. 하지만, 요구사항이 복잡 할 때 바로 작성한 코드는 빨리 나올 수도 없고, 간결한 형태를 유지하기 힘들어 진다. 이것은 글을 쓰는 것과도 비슷한데, 간단한 메모가 아닌 이상 꼭지를 정리해놓는다거나 전체 흐름을 구상하지 않고 바로 글을 쓰면 그 글은 꼬불 꼬불, 갈팡 질팡 길을 헤매기가 일쑤이다. 이 글 조차도 꼭지를 먼저 다 적어놓고 안에 내용을 생각해 본 다음 작성하고 있다. 기승전결도 잘 맞춰가며ㅎ

프로그래밍도 글을 쓰는 것처럼 의미있는 단락들이 각자의 위치에 맞게 잘 배치되어 완성이 된다. 글에서의 단락은 프로그램에서 하나의 모듈이라고 보면 된다.

TDD는 보통 단위 테스트 구성을 중심으로 진행이되는데, 단위 테스트를 구성하다보면 자연스럽게 요구사항을 의미있는 단위의 모음으로 구성하게 된다. 이것이 TDD의 가장 큰 장점이다.

요구사항을 충실히 반영한다.

개발자가 기획, 디자이너와 협업 할 때 가장 큰 문제점은 아마 의사소통의 문제가 아닐까 싶다. 누구의 문제라기보다 서로 생각하는 배경이 다르기 때문에 어쩔 수 없는 부분이 있다. 그럴때 일 수록, 요구사항을 꼼꼼히 다시 정의해보고 재 확인해 보는 것이 중요하다.

요구 사항을 막상 구현을 하다보면 자연스럽게 보다 구체화해야 한다. 이것은 거의 필수불가결한 상황인데, 그 구체화 과정을 좀 더 분명이 해 줄 수 있는 것이 Test Case가 될 수 있다.

요구사항 -> 구현 보다 요구사항 -> 테스트 케이스 -> 구현 의 과정이 좀 더 매끄럽다. 이 과정에서 테스트 케이스에는 최초 요구 사항에는 담겨있지 않은 구체화된 요구사항이 포함되게 되어 있다. 그것은 다른 개발자가 코드를 이해하는데 도움이 될 수 있으며, 개발자 역시 구체화된 요구사항에 맞게 편하게 개발 할 수가 있다. 물론, 개발자가 정한 것이지만, 개발자가 정한 것이 다른 개발자와 본인에게 도움이 될 수 있다는 뜻!

테스트는 어차피 해야 할 일이다.

이건 더 말할 필요도 없을 것 같다. 테스트는 어차피 해야 한다. 쉽게 반복적으로 할 수 있으면 더 좋다. 한 번만 써도 좋은데, 결국 여러번 쓰게된다. 그러니까 TDD 고고!

Test Framework으로 Jest 선택

본 프로젝트에서는 Jest를 사용하기로 했다. 즐거운 테스팅 프레임웍이란다! 얼마나 자신만만 캐치프라이즈인가.ㅋ 추천도 많아서 고민없이 Jest를 선택했다! 고고!

Jest is a delightful JavaScript Testing Framework with a focus on simplicity. It works with projects using: Babel, TypeScript, Node, React, Angular, Vue and more!

사실 TDD에 대해서 고민을 많이 덜 수 있게 된대에는 Framework의 발달도 크게 한 몫 했다. 요즘 다양한 Framework이 많이 있지만, Test Framework도 꾸준히 발전해서 개발자들의 수고를 덜어 줄 뿐만 아니라 생산성을 팍팍 늘려주고 있다.

Test Case 먼저!

TDD의 핵심은 테스트 케이스를 먼저 구성하는 것이다. 간혹 코드를 먼저 구현하고 테스트를 짜는 경우가 있는데, 결과는 같을지라도 가능하면, 테스트를 먼저하는 것이 좋다. 요구 사항을 파악하고, 재정의하고, 단위를 구분한 다음 코드를 구현하는 것이 보다 효과적이기 때문이다. 발표자료의 목차를 먼저 뽑는일이나 오늘 해야 할일 먼저 정리해 놓고 하나씩 체크해가면서 일을 진행하는 것이랑 비슷한 느낌이다.

TDD가 처음이라면, 테스트를 먼저 짜는 것이 쉽지 않을 수 있는데, 주어진 요구사항을 테스트 할 수 있는 수준으로 재정의 한다는 관점으로 접근하면 좋을 것 같다. 나도 처음엔 TDD에 대해서 매우 비판적이었다. ROI가 안나오는 일이라고 생각이 되었는데, 막상 해보면, 생각보다 시간이나 노력이 많이 들지 않으면서도, 당장 테스트 외적인 것에서도 이득을 좀 볼 수 있어서 좋다. 그래서 꼭 한번 해보라고 권하고 싶고, 나도 한번 제대로 해보려 한다.

Test 먼저짜고 Red에서 Green으로!

테스트를 구성하고, 그 테스트가 깨지는 것을 보고, 코드를 작성한 다음 테스트가 성공하는 것을 확인한다. 이 작은 순환을 계속 반복하면서 코딩하는게 익숙해지면 참 좋다. :)

출처: https://blog.dramancompany.com/2016/08/안드로이드에-테스트-도입하기

마치며

이 글을 올릴때쯤 TC 몇개와 함께 모듈이 작성되어서 조금씩 올라가 있을 것 같다. 여러개의 프로젝트를 동시에 하다 보니 속도가 안나는데, 그래도 짧게 짧게 끊어 갈 수 있도록 도와주는 것이 TDD이기도 하다!ㅎ

T.Viewer (Tizen Log Viewer)