[Flutter] 유닛테스트

처음 유닛테스트를 접했을 때는 이거 왜하지? 라는 생각이 들었다.

그런데 지금은 테스트 코드 짱짱맨을 외치며 열심히 TC를 작성하고, 더 나아가서 구현 테스트, 테스트 자동화, 몽키 테스트 같은 다양한 영역을 경험해봤다.

한창 회사에서 안드로이드 앱을 개발하면서 몽키테스트로 아니 무슨 이런곳에서 에러가나냐 싶은 경험도 했었고, 다른 사람이 수정한 코드로 인해 내 TC가 깨지거나, 반대인 상황을 겪으며 테스트 코드의 유용함에 대해 많이 깨달았다.

그런데 그 뿐 만이 아니라, 레거시 코드에 유닛 테스트를 도입하면서 정말 말그대로 개고생을 했고, 테스트 하기 좋은 코드에 대해 관심을 갖게 됐다. 그리고 테스트하기 좋은 코드를 짜면 자연스럽게 조금 더 깔끔한 구현이 된다고도 느꼈다.

아직 아쉬운 부분은 TDD까지 제대로? 겪어보진 못했다는 점..뭐 그러나 개발할 날은 많고도 많으니 앞으로 할 프로젝트에서 책에서 보는 TDD나 요새 패캠에서 듣는 강의들 기반으로 한번 연습해봐야지

테스트에 대한 서론은 여기까지하고 Flutter에서 유닛테스트 작성하는 방법이나 공유해보고자 한다.

 플러터 TC는 되게 간단하게 짤 수 있다. 물론 mocking같은게 들어가기 시작하면 다 귀찮은 작업들이 들어가지만, 초반에는 최대한 mocking없이 유닛테스트를 작성하려는 코딩 습관을 들이는 것도 나쁘지 않을거라고 생각은 한다...(실천이 어려워서 그렇지 ㅠ)

 어쨋든 프로젝트를 만들면 자동으로 test폴더가 만들어진다. 없다면 그냥 수동으로 만들어도 관계없다. 그 안에다가 ooo_test.dart로 만든다. 파일 이름이 컨벤션인지는 잘 모르겠는데 widget_test.dart가 기본적으로 만들어져 있는 파일이라 아마 컨벤션이겠지 하면서 따라 만들었다.

 보통 유닛테스트하면 가장 기초적인게 sum함수 테스트하는 코드인데,, 솔직히 유닛테스트 처음 배우는 입장에서 이거 보면 에게? 하는 생각이 많이 들지 않을까 싶다. 왜냐면 내가 처음에 그랬기 때문에.. 학부 3학년 때 소프트웨어 공학 시간에 Junit에 대해 배웠는데, 지금 생각해보면 좀 더 deep하게 테스트 코드와 TDD에 관해서 다룰 수 있지 않았을까 하는 아쉬움은 있다. (너무 사용법만 배우고 넘어가 버려서..)

 그래도 일단 테스트를 어떻게 짜는지 정도는 간단하게 알아보면 좋으니까 한번 testable.dart를 만들어서 더하기 함수를 하나 작성해보자.

 

 그리고 test폴더에다가 testable_test.dart를 만들고 다음과 같이 작성하자.

 일단 플러터 테스트 코드는 main 함수 안에서 돌아간당.. 그래서 먼저 main함수를 만들고 그 안에서 flutter_test 라이브러리에 정의돼있는 test함수를 호출한다. 첫 번째 매개변수는 테스트 케이스 제목이고, 두 번째 매개변수가 함수로 들어가는데 이게 테스트 body라고 생각하면 된당. 참 쉽죠잉?

 테스트 body를 보면 먼저 testable에 작성한 더하기 함수에 1, 2를 넣고 result에 받는다. 당연히 result는 3이겠지?
그리고 8번째 줄에 expect함수를 이용해서 두 값을 비교해준다. 이게 같으면 테스트 성공이고, 다르면 테스트 실패다.
단순히 단일 케이스를 테스트 해보는 경우도 있고, 이걸 CI를 이용해 빌드, 또는 github에 푸쉬했을때 모든 테스트 케이스를 자동으로 실행하게 할 수도 있다.

 솔직히 이 예제만 보고 아 유닛테스트 짱짱맨을 외치기에는 무리가 있다. 너무 간단한 함수고, 함수 하나만 테스트하는걸 가지고 테스트 코드의 장점을 얘기하기에는 많이 부족하지.. 그러면 테스트 코드의 장점을 이해하려면 어떻게 해야할까?

 일단 직접 테스트 코드를 열심히 짜보는게 최고인것 같다. 일단 내 경험 상 일반 대학교 학부생(코딩을 많이 해보지 않은 정말 일반적인 학생..내가 딱 이 경우 였음)의 경우 테스트 코드에 대해 거의 잘 모르는 경우가 대다수이다. 학교 커리큘럼에서도 깊게 다루는 것 같지는 않고. 물론 우리 학교만 그런거였을수도 있지만, 어쨋든 팀 프로젝트나 동아리 활동같은것을 하면서 틈틈히 테스트 코드를 작성해보는게 제일 좋다. 그럼 이 때 마음가짐은 어떻게 잡는게 좋을까, 나같은 경우는 억지로라도 내 코드의 결과를 내가 증명한다 이런 생각을 하긴 했다. 물론 처음에 귀찮은데 주변에서 테스트 코드 좋다고 외치는 친구가 하나 있어서 그랬지만.. 열심히 짜다 보니, 테스트 하기 불편한 코드에 대한 나름의 주관도 생기고, 그런 구조를 피하려다 보니 자연스럽게 OOP나 더 나가서는 FP쪽에도 관심이 생기더라.
 거기에 CI에 테스트 붙여보면서 devOps쪽도 힐끗 봐보고, 초장에 얘기한 것 처럼 내 수정사항이, 또는 남의 수정사항이 기존 테스트 코드를 깨트리면서 버그의 가능성을 미리 잡는 경험등을 통해 테스트 자동화에도 관심이 많아졌다.

 물론 아직 갈 길은 멀지만 테스트 코드를 통해 되게 많은걸 배운 것 같다. OOP에서 강조하는 여러 원칙들이라던지, 테스트 가능한 코드를 짜는게 크-린한 코드에 한 걸음 더 가까이 다가간다는 느낌? 말로 설명하기가 넘 어렵넹.. 어쨋든 여러분 테스트 짜보세요. 좋습니다..