본 게시물은 테스트 코드에 대해 알아본 내용을 공유합니다.
테스트 코드란
테스트 코드란 말 그대로 테스트를 위한 코드 입니다.
개발을 마치고 요구사항에 맞게 시스템이 잘 동작하는지 보기 위해 테스트 코드를 작성합니다.
테스트 코드를 짜는 이유
우리는 구현한 기능을 직접 하나하나 테스트하려면 시간도 들이고 번거롭게 됩니다. 그러나 테스트를 코드로 작성하게 되면 원하는 기능의 테스트를 자동으로 실행할 수 있습니다.
이때 이런 의문이 들곤 합니다.
브라우저에서 확인하면 바로 동작하는데 테스트 코드를 작성해서 확인을 해야 할까? 🤔
물론 테스트 코드를 작성하는 데 많은 시간을 뺏길 수 있습니다.
우리는 부수 효과 (side effect) 에 집중해야 합니다.
부수 효과란 만들어진 목적과는 다른 효과 또는 부작용을 뜻합니다. 쉽게 말해, 예측하지 못한 일을 의미합니다.
이러한 부수 효과는 사용자의 입장에서 서비스에 대한 신뢰도를 떨어트릴 수 있습니다.
즉 개발자가 예상하지 못한 일이 있을 수 있기에 이를 방지하기 위해 테스트 코드를 작성합니다.
테스트 코드를 작성하면 테스트를 자동으로 실행하는 것 이외에도 코드를 파악하는 데 도움을 주며 수정할 부분을 빠르게 알아차릴 수 있습니다.
이에 여유가 된다면 테스트 코드를 작성하는 것이 좋다고 볼 수 있습니다.
TDD (테스트 주도 개발)
테스트 코드의 중요성이 높아지면서 TDD라는 방법론이 생겨났습니다.
TDD란 Test Driven Development의 약자로 테스트부터 작성하는 개발방식입니다.
일반적으로 개발자들은 아래와 같은 방식으로 개발합니다.
요구 사항 분석 > 설계 > 개발 > 테스트 > 배포
그러나 이는 몇 가지 문제점이 존재합니다.
요구 사항은 처음부터 명확하지 않을 수 있으며 초기에 완벽한 설계란 어려우며 테스트 비용이 증가할 수 있다는 문제가 있습니다.
이에 다르게 TDD 개발방식은
테스트 코드 작성 > 코드 개발 > 리팩토링
과 같은 형태를 가집니다.
테스트 코드를 먼저 작성하고 그 테스트를 통과하기 위한 최소한의 코드를 생성하는 개발 방식으로 시간이 두 배로 들기에 TDD에 대해 반신반의할 수 있습니다.
그러나 TDD는 테스트 코드를 먼저 작성하기 때문에 해야하는 일을 분명하게 정의하고 개발하게 됩니다.
이에 우리는 불필요한 설계를 피할 수 있고 정확한 요구사힝에 집중할 수 있습니다.
무엇을 테스트 코드로 작성할까
어떤 걸 테스트 코드로 작성하고 얼마나 작성을 해야 하는 걸까?
먼저 테스트가 필요한 우선순위를 두고 테스트 코드를 작성하면 효율적으로 작성할 수 있습니다.
우선순위를 정할 때는 사용자의 입장이 되어보아야 합니다.
사용자의 입장에서는 nav든 div든 신경 쓰지 않고 어떤 기능을 하는 지를 신경 쓰게 됩니다.
사용자의 관심사를 중점적으로 우선순위를 작성하면 무엇을? 이라는 질문이 쉽게 해결될 수 있다고 생각합니다.
즉 사용자가 사용할 가능성이 없는 메소드는 우선순위에서 밀린다고 볼 수 있습니다.
그럼 테스트 코드 얼마나 작성해야 할까?
테스트 코드를 모두 작성해야 하는 것인지에 대해 궁금하다면 코드 커버리지에 대해 알아야 합니다.
코드 커버리지(Code Coverage)란 테스트 케이스가 얼마나 충족되었는지를 나타내는 지표입니다.
테스트 코드가 실제로 몇 퍼센트를 검증하고 있는지 볼 수 있어 이를 통해 현재 작성된 테스트 코드의 수가 충분한지 판단할 수 있습니다.
좋은 테스트 코드
그렇다면 좋은 테스트 코드는 뭘까요?
사실 이 질문은 다양한 요인에 의해 다르겠지만 아래와 같이 정리해보았습니다.
-
테스트 코드의 실행 속도가 빨라야 한다.
-
버그를 검출할 수 있어야 한다.
-
테스트 결과는 일관성이 있어야 한다.
-
의도가 명확히 드러나야 한다. (가독성)
테스트 종류
테스트의 종류로는 정적 테스트를 제외하고 주로 이 3가지를 진행합니다.
-
Unit Test (단위 테스트)
-
Integration Test (통합 테스트)
-
E2E Test (End-to-end Test)
이 3가지에 관한 내용은 다음 포스트에서 보실 수 있습니다.
마무리
테스트 코드를 통해 리팩토링을 더욱 쉽게 진행할 수 있으며 테스트 코드는 안전성과 생산성에 직결되기에 더욱 탄탄한 서비스를 개발할 수 있을 것입니다.
설명하는 과정에서 혹시나 잘못된 부분이 있을 시 피드백 부탁드립니다.
글 읽어주셔서 감사합니다! 🙂
