테스트 코드를 어떻게 작성하시나요?

안녕하세요. 질문하신 테스트코드가 단위 테스트(Unit Test) 코드를 말씀하시는거로 이해하고 답변 드리겠습니다. 단위 테스트 코드를 작성하실 경우 개발한 비지니스 로직에 대한 테스트뿐만 아니라 다음과 같은 이점이 있습니다. ✔️ 변경사항이 발생했을 때 기존 기능 동작에 영향이 없는지 가장 빨리 확인해 볼 수 있습니다. 이는 팀원들끼리 같이 협업하는 코드일수록 빛을 발합니다. ✔️ 테스트 코드를 작성하기 어렵거나 검증하기위한 절차가 복잡하다면 잘못 짜여진 코드일 가능성이 높습니다. 이럴 경우 코드에 대한 리팩토링을 고려할 수 있고 더욱 완성도 높은 코드가 만들어질 수 있습니다. ✔️ 잘 작성된, 그리고 가독성이 높은 테스트 코드는 개발한 코드의 기능을 잘 설명할 수 있는 또 하나의 문서가 될 수 있습니다. 파라미터가 어떻게 들어가고 제한사항이나 최대, 최소로 동작하는 값이 어느것이며 어떤 형태로 결과를 도출하거나 어떤 상태값들이 있는지를 예제 코드처럼 알수가 있습니다. 위에서 언급드린 테스트코드의 이점을 살리기 위해서는 무엇보다도 다양한 유스케이스에 대해 테스트코드가 작성되어야하고 각 테스트 코드가 테스트 하는 목적을 이해할 수 있게 가독성이 높아야 합니다. 이를 위한 첫 단추로 테스트코드 함수 이름이 명확해야하고 유명한 given, when, then 규칙으로 코드를 작성하는게 좋습니다. 주석 혹은 junit 을 사용하실 경우 @DisplayName 어노테이션등을 사용하여 테스트코드를 설명하는 description 을 작성하는것도 좋습니다. 저의 짧은 식견이 조금이나마 도움이 되시길 바랍니다.

단위 테스트가 내가 고려한 엣지 케이스를, 내가 실행해서 무슨 의미가 있나 싶은 점 공감합니다. 이미 잘 작동하는 뻔한 케이스만 검사하게 될 테니까요. 그래서 단위 테스트는 사실 1차적인 테스트고, 실무에서는, 이후에도 다른 단계의 테스트들을 합니다. 규모가 좀 큰 회사들은 QA 팀이 따로 있어서, 배포 전에 기능 테스트를 전담하는 인력들이 있기도 합니다. 암튼, 코드 작성자가 1차적으로 하는 단위 테스트가 주는 장점이 많이 있겠지만, 아래의 사항들이 "추가로" 도움이 된다고 생각합니다. 우선, 내가 작성한 코드의 사용예 역할을 합니다. 어떤 케이스에 성공값이 나오고, 어떤 경우에 이런 실패값이 나오며, 어떨 때는 이런 예외가 발생한다라는 문서화 역할을 코드로써 할 수 있습니다. 오랜 시간 후의 내가 봤을 때도 이해를 도울 수 있고, 당장의 동료가 보고 이해하기 좋을 수 있습니다. 다음, 코드를 한 번 작성하고 끝나면 큰 의미가 없겠지만, 대부분 의미 있는 프로젝트는 지속적으로 기능이 추가되고 코드가 변경되고 불필요한 코드가 제거되는 과정을 거치는데, 그러다보면, 잘 작동하던 코드에 악영향을 끼치기도 합니다. 그럴경우, 단위 테스트 코드를 작성해 둔 부분에서, 금방 오류상황을 발견할 수 있게되어, 재빠른 대처가 가능하고, 이 덕분에 리팩토링 작업을 좀더 자신있게 할 수 있습니다. 단위 테스트는, 보통 컴파일 성공하고 바로바로 자동으로 다 돌리는 편이니까, 내가 손으로 한두 번 확인하고 끝난 게 아니라, 내가 확인하는 내용을 컴파일(테스트)마다 거의 매번 돌려주는 보호막 역할을 합니다. 또 만약, 파이썬이나 자바스크립트 같은 동적 타입 프로그래밍 언어라면, 실행 시간에 발견될 사소한 문법적 오류를, 테스트 코드가 한 번 걸러 줄 수 있는 역할을 합니다. 엣지케이스는, 말그대로, 실패와 성공의 경계 근처에 있는 값들을 위주로 검사하면 좋습니다. 확실히 통과할 값과, 확실히 실패해야 하는 값, 그 경계에 있는 값을 테스트 케이스로 넣어서 테스트하면 든든하겠죠. 장점은 이런 것들이 있고, 한편 단점으로는.... 작성하기가 귀찮습니다. ㅎㅎ. 특히 각종 상태와 상호 작용을 덕지덕지 품고 있는 코드를 테스트하려면 Mocking을 한다거나, 테스트 환경 상태로 만들어내는 작업이 여간 번거로운 게 아닙니다. ㅎㅎ

Refactoring이라는 책의 저자는 수시로 테스트 코드를 수정해서 일부러 실패 시킨다더군요. 설마 이런 값은 안들어오겠지 하는 케이스도 넣어보고 api 호출이라면 타임아웃되거나 네트웍 오류가 발생하는 케이스 등 계속 습관 처럼 작성하다보면 넣어야할 케이스가 보일거에요. 그리고… 모든걸 test만으로 잡아낼수는 없어요. 누락된 케이스를 경험하면 그것부터 잊지 않도록 해봐요.

1인 개발이 아니시면 다른분에게 테스트를 맡겨보세요

테스트 코드를 먼저 작성합니다. 자동완성을 못한다는 것이 조금 슬프지만, 테스트 코드를 먼저 작성할 경우 얻는 이득이 많습니다.

bdd를 사용해보시는건 어떤가요? 테스트 시나리오 작성에 대한 고민이 어느정도 해결될 것 같습니다.