테스트에 대해서
슈뢰딩거의 고양이같은 존재가 바로 테스트가 아닐까?
부트캠프에서는 테스트에 대한 존재를 매우 강조를 많이 했다.
(근데 작성 방법 안알려줌)
그리고 신입 면접을 보는 과정 속에서도 테스트에 대한 강조가 상당히 많이 드러났다.
현업에 와서 테스트 코드를 작성하는 모습을 보면서 오옷... 이게 현업...!? 이라는 생각도 했다.
근데 과연, 테스트가 은탄환일까?
직접 경험해본 테스트에 대해서 적어볼까 한다.
유닛 테스트, E2E 테스트
유닛 테스트
현실적으로 작성할 만한 테스트다.
로직 검증을 하기 위하여 주로 사용된다.
시작부터 문제점이 보이는데 알겠는가?
로직 검증을 하기 위하여 작성되는 테스트 코드이다보니, DB에 관련된 테스트가 불가능하다.
보통 위의 사진처럼 로직 검증을 하는 중, DB가 필요하다면 Mock의 방식으로 선언을 하여 테스트가 진행된다.
그러다보니 DB 작업에는 무결하다는 것을 가정하고 짜게 되는데...
초반부에 잘 모르던 시절 쯔음, 유닛테스트를 믿고 별다른 제스처를 하지 않다가,
크리티컬한 문제가 발생하면서 풀필먼트를 한창 작업하던 중에는 유닛테스트보다는 E2E 테스트 위주로 작성을 하게 됐다.
아무튼, 사유는 역시나 DB 쿼리가 잘못 작성이 되어있었고...ㅋ.... 전수조사를 하게 됐다.
하지만 일장일단이 있는 것 처럼 엑셀로 대량 출고를 업로드하는 로직에서는 유닛테스트가 정말 큰 도움이 됐다.
즉 로직에 검증이 상당히 많이 필요하다면 유닛테스트를 많이 작성해두는게 좋다.
흔히 말하는 테스트 커버리지를 높은 퍼센테이지로 적용을 해두면 정말 최고다.
왜 최고냐고?
리팩토링 할 때 진짜 기가막힌 가이드가 되어준다.
흔히 말하는 잘 읽을 수 있는 코드, 잘 작성이 된 코드가 무엇이냐고 물어볼 때 이렇게 대답을 할 수 있지 않을까?
테스트 코드가 작성되어있는 코드가, "좋은 코드"라고 말이다.
왜 이렇게 강조하냐면... 한 1년차 무렵, 다른 분이 작성한 수백줄짜리 코드를 리팩토링하는데
테스트코드가 있어서 좀 쉽게 작업한 적이 있다. 그냥 코드가 쏙쏙들어옴
아마 다른 분들도 비슷하게 공감을 해주실 수 있지 않나 싶다.
E2E 테스트
큰 마음을 먹고 작성해야 하는 테스트다.
E2E부터는 진짜 큰 마음을 먹어야한다고 생각한다.
우리가 하고싶은게 그냥 회원가입이 아니기 때문에..... 테스트를 위한 코드를 작성해야 하는 경우도 발생한다.
심지어 E2E 테스트는 서버 + 디비를 모두 사용하기 때문에 빠른 속도의 테스트도 불가능하다.
인메모리 디비도 고려를 했으나, SQLite와 Mysql의 동작이 정확하게 일치하는가? 에서 X 라고 생각하여 인메모리 디비는 고려하지 않았다.
그래서 CI에 넣기에도 매우 어렵지만, 한번 틀만 작성해두면 계속 우려먹을 수 있게 된다.
나같은 경우 NestJS 프레임워크를 사용하면서 Supertest 라는 라이브러리를 사용했는데, 그렇게 어렵지 않았다.
(조만간 작업중인 레포에서 테스트 코드를 추가해놓을 계획에 있다, 잠시 다른 작업중이라 밀리긴 했는데 아무튼 넣어놓을 예정)
물론 초반에 틀을 짜놓는 과정이 매우매우 지난 할 수 있다.
서버를 올리면서 뼈대가 되는 데이터를 모두 생성하는 과정이 필요하기 때문인데
이 부분에서 AI에게 큰 도움을 받을 수 있게 됐다.
다양한 조건의 테스트를 하기 위해서는 정말 다양한 데이터가 포함이 되어있어야하는데
이러한 데이터를 넣어주는것이 E2E 테스트에 있어서 제일 큰 벽이였다고 생각한다.
근데 이걸 이제 AI가 짜줌
간단한 수준의 테스트코드는 AI가 다 짜주기도 하지만, 데이터를 제너레이팅 하는 과정이 단축된 점이 난 매우매우 만족스러웠다.
최근에 조건이 많고 데이터베이스 쿼리에 의존하는 로직을 짤 일이 생겼는데
이러한 부분을 AI로 하여금 빠르고 정확하게 테스트를 할 수 있어서 AI의 발전이 확실히 큰 영향을 주긴 했구나.. 라는 생각을 했달까
그래서 테스트코드 많이 짜나요?
그럴 줄 알았는데, 아니더라구요?
나야 짜는 편이다, 회사에서도 권장하는 방식이고
읽기 좋은 코드를 짜기 위하여 이것저것 장치를 해놓는 편이라 테스트도 가급적 짜려고 노력하는데....
과거에 테스트 코드를 짜냐고 트위터에 올려본 적도 있고, 주변 사람들에게 물어본 적도 있었는데
안짠단다, 못짜는게....아닌가?
테스트코드도 결국 코드를 짜는 것이기에 생산성(?)에 있어서는 떨어지는 것이 확실하지만
유지보수의 측면이라거나 안정성을 생각해보면 미래의 생산성에는 더 큰 보장이 된다고 생각하는데, 그게 언제나 100%는 아닌 듯 하다.
정말 많이 짜지 않는다는 이야기를 듣고 조금 당황도 했다. (사실 지금도 의아스럽긴함, QA가 있나?)
아 그리고 게임쪽은 짜는게 매우매우 힘들어서 안짠다.는 이야기도 들었다, 이쪽은 너무 예외변수가 많아서 짜지 못하는 것 같기도 하고
백엔드가 아닌 프론트의 경우도 짜는게 쉽지 않다고는 들었다.
테스트는 선택이 아닌 필수! 라는 캐치프라이즈(?)가 달릴랑 말랑 하던 시기에 이러한 답변을 받아서
흠.... 이게 은탄환은 아니구나 라는 생각을 하게 됐다.
사실 개발쪽에는 정답이라는 말이 참 없는 것 같긴 하다. Case By Case가 너무 많아서
결론
나는 최대한 짜려고 노력을 하지 않을까 싶다.
가능하다면ㅋㅋ 짜볼 것 같다.
언제나 무조건 짠다는 말은 조금 위험하지 않을까 싶기도 하고
상황이라는게 그렇게 만만치 않기 때문에, 그것도 좀 어려울 것 같기도 하고
그래도 시간 들여서 짜놨을 때에는 확실히 큰 도움이 됐다!
끝
