어떤 시스템이 필요할까
혼자서 개발한다면 프로젝트에 대해 자기가 다 알고 자기만 알면 된다. 코드를 수정했을 때 기능에 문제가 없는지 테스트도 조금의 귀찮음만 감수하면 문제없다.
그런데 두명 이상이 한 프로젝트에서 같이 개발할 때부터 문제가 생긴다. 마치 서버도 한대만 있으면 문제가 없지만 두 대 이상으로 가면 데이터 정합성 등 따져야할 문제가 많아져 복잡해지는 것처럼 느껴진다.
지금 내가 생각하는 문제는 다음과 같다.
1. 현재 코드에 문제가 없는지 확인하는 것을 개인 재량에 맡기면 문제가 생길 수 밖에 없다. 그리고 문제가 생겼을 때 책임이 개인에게 가기 때문에 개인에게 부담이 될 수 있다. 또한 사람은 까먹을 수 있기 때문에 항상 더블 체크가 필요하다.
2. 기능 테스트를 매뉴얼하게 하면 놓치는 부분이 생길 수 밖에 없다.
그래서 코드 품질을 유지하는 시스템이 갖춰져야 한다고 생각했다.
- dev나 main 브랜치에 코드가 머지될 때는 github action으로 코드 품질을 검사한다. 머지하기 전에 전체적으로 코드에 문제가 없는지, 기능은 모두 정상 동작하는지 확인하면 좋겠지만 시간에 쫒기거나 마음이 급하면 까먹을 수 밖에 없다. 그래서 적어도 시스템적으로 이런 부분을 보완하자.
- lint와 prettier로 코드 품질에 문제가 없는지 확인한다.
- 안드로이드, iOS에서 빌드는 잘 되는지, 모든 기능은 문제 없는지 반드시 확인한다.
- 서비스 기능 테스트를 자동화한다. - 지금까지 손수 눌러보며 확인해보았는데 이 과정에서 몇몇 부분을 빼먹기도 하고 테스트하기 귀찮아서 넘어 가기도 했다. 그러면 머지하고 보니 어떤 기능이 동작하지 않는 등 심각한 문제로 이어졌다. 그래서 적어도 엔드 투 엔드로 사용자 관점에서 기능이 모두 동작하는지 확인할 필요가 있다고 생각한다.
- expo에서는 e2e 테스트로 maestro를 권장해서 이것을 사용했다.
- 머지 하기 전 PR에서 github action으로 코드 품질을 검사하지만 이때까지 문제를 쌓아두면 PR을 올릴 때 심리적 부담감이 커진다. 그래서 커밋 단위에서 코드 품질을 검사해 부담을 줄이자. - lint를 할 때 수정할 사항이 10개를 넘어가면 하기 싫어지는 경우가 많은 것 같다.
- husky로 git hook을 설정하고 lint-staged로 커밋에 해당하는 부분의 코드 품질을 검사한다.
E2E 테스트
https://maestro.mobile.dev/
get started 보고 세팅한 다음
팀원이 작업하던걸 바톤 터치해서 마무리했다. 크크
작업 중 만났던 문제는
1. iOS를 테스트할 때 text를 기반으로 tapOn할 때 정규표현식으로 작성된 것을 정규표현식으로 인식하지 못하는 문제가 있었고 테스트 환경에서 언어를 한국어로 통일하는 것으로 해결했다.
2. iOS에서 모달에 있는 텍스트를 인식하지 못해 tapOn을 하지 못하는 문제가 발생했고, tapOn 해야하는 대상에 testID를 설정하는 것으로 해결했다.
github actions
아쉽게도 maestro를 github actions에 추가하려면 maestro cloud 서비스를 이용해야 한다. 그래서 대안으로 현재 PR 양식인
## What is this PR?
## Changes
## Screenshots
## Test Checklist
에서 Test Checklist에 maestro를 로컬에서 실행하고 그 스샷을 첨부하도록 하는 것을 생각했다.
그외 lint, prettier, tsc, android, ios 빌드 테스트는 gpt한테 물어보며 작성했다.
husky & lint-staged
https://typicode.github.io/husky/
https://github.com/lint-staged/lint-staged
husky와 lint-staged에 대해 설명하는 블로그들이 많았는데 내용들이 옛날 내용이거나 그런 것들이 많아서 그냥 get started 보는게 나은 것 같다.
각각에 대해 시간이 난다면 별개의 포스트로 자세히 블로그에 적어보고 싶다...
