테스트 코드의 편리함

인턴을 하면서 테스트 코드는 그냥 귀찮은 부가적인 일이라고 생각했었다. 회사에서 뒤늦게 테스트 코드를 도입하려다보니 그에 따른 비용이 너무 컸기 때문이었다. 이미 코드가 다 작성되어있고, 그에 따른 테스트 코드를 이후에 작성하는 것은 다른 일이 밀려있는 상태에서 꽤 큰 작업이었다.

옛날부터 했었어야 되는 일이라는 말을 꽤 들었었는데, 직접 작성해보니 왜 그런 것인지 알 것 같았다. 처음 들었을 때는 어떻게 테스트 코드를 먼저짜고, 그 이후에 코드를 작성해? 라고 생각했는데 한번 해보니 몇번 해보다보면 그렇게 어려운 일도 아니겠다는 생각이 들었다.

코드를 다 작성하고 테스트를 해보니, 한눈에 모든 테스트 결과를 알 수 있어서 좋았다. QA 업무에서 일일히 테스트 하던 옛날 일이 떠오르기도 했다. 한번 버그가 발생했을 때 모든 메뉴에 같은 작업을 반복했던 것을 떠올려보면, 테스트 코드를 미리 작성해놓는 것은 확실하게 이후 비용을 줄여줄 수 있을 것 같다.

하다보니 쉘 스크립트도 왜 까다로운 문법이 있음에도 사용하는 지 짐작이 갔다. 자동화는 정말 편리한 것!

오늘도 또만난 비동기

싱글 스레드 언어인 자바스크립트와는 떨어질 수 없는 개념인가보다. 웹을 처음 공부했을 때 ajax로 데이터를 받아오는 것을 보면서, 아. 따로 돌아가는거구나. 쉽네? 라고 생각하고 깊게 공부하지 않았던 나를 원망한다..

어렴풋이 이해하고 넘어가서 그런 것일까, 너무 비동기에만 꽂혀서 그쪽으로만 해결하려고 해서 그런 것일까 비동기만 만나면 머리가 굳는 것 같다. 오늘 회고 시간에 정리해보려고 했는데, 시간이 모자라서 정리를 다 완료하진 못했다. 틈틈히 해둬야지.

TDD(Test Drive Development)

  • 개발 이후에 테스트코드를 작성하는 것이 아니라, 테스트코드를 먼저 작성하고 개발하는 것을 말한다.
  • 함수 단위로 테스트 코드를 구현하고, 이 테스트를 통과하는 함수를 구현하면서 정상 동작하는 지 지속적으로 관찰하며 Refactoring을 거치는 개발 방식이다.
  • 요구사항이 바뀌기 쉬운 프로젝트, 처음 해보는 프로젝트, 코드가 자주 바뀌거나 유지보수하는 사람이 자주 바뀌는 경우와 같이 불확실성이 높은 경우 TDD를 하는 것이 좋다.
  • TDD를 통해 보는 사람이 프로그램의 동작을 쉽게 파악할 수 있고, 때문에 이에 대한 피드백이 즉각적으로 들어올 수 있다.
  • 하지만 단기간에 프로젝트를 끝내야하는 경우 테스트 코드와 구현 코드를 모두 구현해야 하므로 좋지 않을 수 있으며, TDD에 익숙하지 않는 개발자에게는 낯설 수 있다는 단점이 있다.

반성하기

오늘의 체크포인트는 모두 달성하긴 했지만, 미션의 제약사항을 제대로 지키지 못했다. 비동기 이후에 실행되는 동기 동작이, 비동기 Task가 끝난 이후에 출력되도록 해야했는데 실행 부분 코드는 바꾸지 않아야하는 제약이 있었다. 주변 사람들은 대부분 전역 Queue를 사용해 구현했고, 내가 보기에 그 방법은 왠지 적합해보이지 않았다.

그런데 해설을 보면서 마스터님도 같은 방식으로 구현한 것을 보았다. 그걸 보면서 적합해보이지 않는다는 것은 그냥 핑계고, 귀찮았던게 아닐까 하는 생각이 들었다. 물론 더 좋은 방법이 있지 않을까, 생각하고 비동기를 계속 찾아보면서 여러번 삽질을 하긴 했지만, 결과적으로 제약을 어기고 테스트 코드를 변경했고 아는 방법이 있음에도 그대로 구현하지 않았다.

조금 귀찮고 별로인 방법같아도, 그게 최선이라는 생각이 들 때는 더 좋은 방법이 있을 것 같더라도 먼저 구현해보는 용기를 가져야겠다는 생각이 들었다. TDD가 동작을 지속적으로 관찰하며 Refactoring을 거치는 과정인 것 처럼, 코드는 아무리 복잡해보이거나 비효율적이더라도 기능만 잘 분리되어있으면 나중에 쉽게 고칠 수 있다!

지난번 마스터님과의 티타임에서 마스터님의 말처럼, 구현을 먼저, 최적화는 나중에! 사실 현업이었다면 Queue라도 써서 좀 더 범용화할 수 있는 방법이 좋았을 것이라는 생각도 든다. 야매는 갈 수록 코드가 꼬이는 법이니까. 다음 미션에는 좀 더 분발할 수 있도록 해야겠다.