테스트로 배우는 러스트

 

러스트에 기여하면서 배웠던 점들 알게 된 점들 깨달았던 점들을 남겨보려고 한다. 

 

우선 러스트의 첫 PR은 문서 수정이였다. 코드 구경하다가 깨진 링크를 발견하였고 이를 수정하는 PR을 올렸다. 이렇게 한번 기여하고 나니까 뭔가 나도 좀 더 기여할만한 것들이 있는지 이슈를 둘러보기 시작하였다. 다른 이야기지만 이렇게 깨진 링크가 있는 Repository가 꽤 많이 있다는 것을 발견하고 러스트로 새로운 프로젝트도 만들어보고 있으니 많관부 (깃허브, 블로그)

 

이후 다른 오픈소스보다 알게된 점인데 러스트의 이슈 관리는 아주 잘 돼있는 편이었다. 라벨링도 다양하게 잘 되어 있었고, E-eazy처럼 난이도로 분리된 것도 있고, E-mentor처럼 멘토가 붙어서 도움을 준다는 이슈도 있었다. 

 

PR을 올리면 자동으로 리뷰어가 할당되었고 리뷰도 48시간 이내에 남겨주었다.

 

문서 작업을 한 후 E-needs-test가 붙은 이슈를 파기 시작했다. 이 라벨이 의미하는 것은 문제는 해결이 됐으나 이를 확인할 수 있는 테스트가 아직 작성이 되지 않은 상황을 의미한다. 즉 회귀 테스트 작성이 필요한 이슈다. 테스팅 컴파일러 가이드와 기존에 작성되어 있던 테스트를 보며 러스트 컴파일러의 테스트 과정을 살짝 엿보고 코드를 작성하기 시작했다. 문서화도 잘되어있고 리뷰도 빠르고 꼼꼼해서 쉽게 배울 수 있었다. 다만 코드가 워낙 많아 이 코드 저 코드 다니며 이해하기가 어려웠다.

 

E-needs-test 라벨이 붙은 이슈가 익숙해지니까 이제 또 다른 라벨에 도전해보고 싶어졌다. 그렇게 도전하게 된 이슈가 E-mentor 라벨이 붙은 이슈였다. 기존의 레거시 테스트들을 개선하기 위한 이슈였다. 테스트의 위치가 tests/ui 상단에 위치한다거나, 테스트 파일의 이름이 애매모호하다거나, 테스트 코드가 무엇을 테스트하기 위한 코드인지 명확하지 않다거나 등등 말썽꾸러기 테스트를 개선하는 게 목표다. 

이 이슈에서 작업을 하면서 주석의 필요성을 느꼈다. 클린 코드를 읽고 주석은 악이며, 주석이 덕지덕지 붙은 코드는 냄새난다 라고 생각했고, 그 뒤로 코드 자체로 의도를 표현할 수 있는 코드를 작성하려고 노력했다. 그런데 아니었다. 코드로는 표현할 수 없는 의도들이 있다. 특히 협업을 하는 상황이라면 더욱더 주석이 필요한 거 같다. 

예를 들어 아래와 같은 코드가 있다고 가정하자.

 

 

문자열에 -를 사용할 수 없다는 것을 확인하는 테스트인데, 어떻게 보면 당연한 소리 아니냐고 생각할 수 있다. 하지만 기존에 문제가 발생했던 상황이 있었고, 이를 주석으로 남긴다면 이 테스트의 필요성이 더욱 각인된다.

 

 

 

이처럼 무엇을 테스트하는지와 연관된 이슈가 있다면 이슈번호를 남겨두는게 훗날 도움이 된다. 그리고 코드 보면 //~ ERROR 이런 식으로도 주석이 작성되어 있는데, 이는 러스트 컴파일러 테스트에서 사용하는 주석이다. 러스트 컴파일러 테스트는 이 주석을 보고 주석으로 작성된 에러와 동일한 에러가 발생하는지 검사하며 테스트한다. 러스트 테스트 몇번 돌려보니까 알게 된 점인데, 러스트 컴파일 후 산출물이 어마어마하다. build 디렉터리에 10GB 넘는 파일들이 만들어진다. 그렇기 때문에 컴파일 시간도 굉장히 오래 걸린다. 러스트가 빠르다는 바이럴은 많은데, 빠른 건 런타임속도지 개발 속도나 컴파일 속도는 내가 경험했던 다른 언어와 비교했을 때 현저히 떨어진다. 

 

 

러스트에서는 doc test라는 기능도 제공하는데, 이건 말그대로 주석에 있는 코드를 테스트하는 것이다. 

 

 

위 코드처럼, 함수에 대해 doc test를 만든다면 사용하는 사람 입장에서 해당 함수의 사용법을 빠르게 파악할 수 있다. 그리고 이 테스트도 cargo test로 테스트 실행 시에 같이 돌아가기 때문에 검증까지 가능하다. 즉 코드만 수정하고 주석은 그대로 남기는 문제를 방지한다.

 

기여하면서 러스트 외에 배운점들은 또 있는데, Git과 Vim에 더 익숙해졌다.

우선 러스트처럼 대량의 코드가 있는 Repository의 경우 젯브레인의 IDE가 맥을 못 춘다. 그래서 터미널에서 놀기 시작했고 vim 명령어와 친해지는 시간이었다.

그리고 또 git rebase -i  명령어도 알게 되었는데, 계기는 리뷰어한테 리뷰받고 수정한 커밋들이 여럿 쌓이니까 리뷰어가 이 커밋들을 squash 해야 merge 시켜주겠다고 하여 로컬에서 squash 하는 방법을 배웠다. 

 

 

이렇게 feat 1,2,3,4 커밋이 있고, 이 네 개의 커밋을 하나의 커밋으로 합치고 싶다면, git rebase -i HEAD~4를 입력하고, 그다음 제일 처음 커밋인 feat 1의 커밋만 그대로 pick으로 남기고 나머지 세 개의 커밋은 squash의 약자인 s로 변경해 준 뒤 저장하고 닫으면 된다. 

 

pick을 s로 변경.

 

그러면 이제 feat 1 하나의 커밋에 나머지 3개의 커밋이 squash 된다. 이후 커밋 메시지 설정하는 창이 나오니 적절한 커밋메시지 남기고 저장하고 창을 닫으면 된다!

 

rebase -i에서 i가 인터렉티브 모드여서 squash 말고도 다른 커맨드도 제공하는데, 재밌는 거 많으니 한번 연습해 봐도 좋을 것 같다. 그리고 새로 열린 에디터에서 커밋 순서를 변경하면 그것도 반영된다. 

 

 

이미 리모트에 올라간 상황이라면 충돌이 발생하는데 그럴 땐 git push --force를 사용하면 된다👍