안녕하세요.
데브피플에서 프론트엔드 개발을 담당하고 있는 Woody입니다.
서비스 개발 과정에서 테스트 코드 작성을 실천하면 더 나은 결과물을 만들 수 있다는 글을 많이 볼 수 있습니다. 실제로 테스트 코드는 서비스의 안정성을 높이고, 기능 추가 및 수정으로 인해 발생할 수 있는 부작용(Side-effect)을 줄일 수 있습니다. 하지만 테스트 코드를 작성하려면 개발 시간이 증가하고, 이를 관리하는 추가적인 유지보수 비용이 발생할 수 있습니다. 오늘은 테스트 코드가 무엇인지, 장단점에 대해서 설명드리겠습니다.
테스트 코드란?
.png&blockId=ed99de2b-3b8c-4ae5-aebe-aa6c9f19978b)
테스트 코드(Test code)는 소프트웨어의 기능과 동작을 테스트하는 데 사용되는 코드입니다. 소프트웨어 테스트는 소프트웨어의 결함을 찾아내고 수정하는 과정에서 매우 중요합니다. 테스트 코드는 개발자가 작성한 코드를 실행하고 예상된 결과가 정상적으로 나오는지 확인하는 데 사용됩니다.
테스트 코드에는 단위 테스트(Unit Testing), 통합 테스트(Integration Testing), E2E(End to End Testing) 등의 다양한 종류가 있으며, 각각의 테스트는 특정한 측면에서 소프트웨어의 동작을 테스트합니다. 이처럼 테스트를 구분하는 이유는 테스트 대상의 범위가 다르기 때문입니다.
개발자는 테스트 코드를 작성함으로써, 개발 과정 중 예상치 못한 문제를 미리 발견할 수 있고, 코드 수정이 필요한 상황에서 유연하고 안정적인 대응을 할 수 있습니다. 이는 곧 서비스의 품질 및 안정성과 직결되어 있습니다.
테스트의 종류
1. 단위 테스트란?
단위 테스트(Unit Test)는 소프트웨어 개발에서 일반적으로 사용되는 테스트 중 하나로, 개별적인 코드 단위(하나의 기능을 하는 코드)가 의도한 대로 작동하는지 확인하는 과정입니다. 예를 들어, 쇼핑몰 서비스에서 상품을 장바구니에 담는 기능을 테스트한다고 가정해 보겠습니다. 단위 테스트는 아래 예시 이미지와 같이 장바구니에 담기를 클릭했을 때 장바구니에 데이터가 담기는 예상 결과를 주는지 코드 단에서 한 번 더 테스트함으로써, 기능이 올바르게 동작하는지 확인할 수 있습니다.
장바구니 담기 기능 예시(쿠팡)
2. 통합 테스트란?
통합 테스트(Integration Testing)는 단위 테스트에서 검증된 개별 모듈(기능)들을 결합하여 그들이 예상대로 상호작용하고 있는지 확인하는 테스트입니다. 통합 테스트는 단위 테스트와 달리 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어 검증할 때 사용합니다.
* 외부 라이브러리 : 소프트웨어 개발자가 특정 기능을 구현하기 위해 사용하는 라이브러리입니다. 외부 라이브러리는 개발자가 직접 개발하지 않고, 소프트웨어 개발 회사나 오픈 소스 커뮤니티에서 제공합니다.
예를 들어, 데이터베이스와 프론트엔드 웹으로 구성된 웹 애플리케이션을 개발한다고 가정해 보겠습니다. 데이터베이스는 웹 애플리케이션의 데이터를 저장하고, 프론트엔드 웹은 사용자에게 보여줄 데이터를 가져오기 위해 데이터베이스와 상호 작용하는 역할을 합니다.
프론트엔드와 데이터베이스의 상호작용
통합 테스트는 데이터베이스와 프론트엔드 웹이 서로 잘 상호작용하고 있는지 확인합니다. 예를 들어, 사용자가 프론트엔드 웹에서 데이터베이스에 데이터를 입력하면, 데이터베이스가 데이터를 올바르게 저장하고, 프론트엔드 웹이 데이터를 올바르게 표시하는지 확인할 수 있습니다.
3. E2E 테스트란?
E2E 테스트(End to End Testing)는 실제 사용자의 시나리오를 테스트함으로써 소프트웨어가 의도한 대로 동작하는지 확인합니다. 예를 들어, 쇼핑몰을 개발한다고 가정해 보겠습니다. 쇼핑몰은 고객이 상품을 선택하고, 결제하고, 배송받는 과정을 거칩니다. E2E 테스트는 고객이 상품을 선택하고, 결제하고, 배송받는 과정을 처음부터 끝까지 테스트합니다. 이 테스트를 통해 E2E 테스트는 고객의 상품 구매 시나리오가 정상적으로 동작하는지 확인할 수 있습니다.
테스트 코드의 장단점
.png&blockId=b622254e-7f43-4b53-9c86-b87f434f8650)
장점
코드 품질 향상
테스트 코드 작성은 서비스의 품질을 향상시킬 수 있습니다. 테스트 코드를 통해 발생 가능성 있는 버그를 사전에 찾아내고 방지할 수 있으며, 이는 개발자가 신뢰할 수 있는 코드를 작성할 수 있게 도와줍니다. 저희 데브피플은 서비스의 핵심 로직에 테스트 코드를 도입함으로써, 버그를 감소시키는 결과를 통해 서비스의 품질을 향상시킬 수 있었습니다.
문서화
테스트 코드는 개발자가 더 빠르게 기능의 동작 방식을 이해하는 데 도움이 되는 문서로 작용할 수 있습니다. 테스트 코드를 통해 코드의 예상 동작을 명확하게 확인할 수 있기 때문에 개발자 간의 커뮤니케이션 향상에도 도움이 됩니다. 데브피플 외주 이후 유지 보수 또는 기능 개발을 위해 내부적으로 새로운 개발자를 고용하게 되는 경우 프로젝트의 코드를 파악하는 시간을 줄일 수 있어 더욱 빠르게 프로젝트 개발에 참여할 수 있습니다.
리팩토링
서비스 출시 후 기능을 확장하시거나 코드 품질을 더욱 향상 시키기 위한 리팩토링 작업을 진행할 경우
이전에 작성한 테스트 코드를 통해 서비스에서 동작하는 기능에 대한 안정적인 확장 및 품질 향상이 가능함으로써, 유지보수 비용을 줄일 수 있습니다.
단점
개발 시간 및 유지보수 비용
아래의 테스트 코드 작성 예시 이미지를 통해 확인할 수 있듯이 테스트 코드 작성은 단순한 작업이 아니므로 프로젝트 개발 일정이 늘어날 수 있습니다. 또한 서비스의 기능이 변경되거나 확장될 때마다 테스트 코드도 함께 수정해야 합니다. 이에 따라 추가적인 유지보수 비용이 발생할 수 있습니다. 저희 데브피플은 테스트 코드 도입에도 프로젝트 개발이 빠르게 진행될 수 있도록 중요 기능들을 사전에 파악 후 부분적인 테스트 코드를 도입하고 있습니다.
React 테스트 코드 작성 예시 이미지
오버 엔지니어링
* 오버 엔지니어링 : 개발 과정에서 소프트웨어의 요구사항보다 더 복잡하고 정교하게 코드를 작성하는 것을 말합니다.
테스트 코드 작성에 과도한 일정을 산출하여 투자하면, 오버 엔지니어링으로 이어질 수 있습니다. 이는 개발 생산성을 저하와 비효율적인 리소스 사용을 초래하여 프로젝트 일정이 늦춰질 수 있습니다. 하지만 사전에 중요 기능을 파악하여 코드의 기능을 테스트하는 데 필요한 최소한의 테스트 코드를 작성함으로써, 개선이 가능합니다.
학습 곡선
테스트 코드를 지원하는 프레임워크와 테스트 코드 작성 방법을 익히는 데 시간이 소요됩니다. 팀 구성원이 테스트 코드 작성에 익숙하지 않은 경우, 적용 전 학습 시간이 소요되며 이로 인해 개발 생산성이 저하될 수 있습니다. 내부적으로 테스트 코드 작성 경험을 공유하고 테스트 도구를 사용하면 테스트 코드를 작성하는 시간을 줄일 수 있습니다.
마치며
테스트 코드를 통해서 모든 버그를 방지할 수 있는 것은 아닙니다. 하지만 서비스를 더 안정적으로 출시하고 관리할 수 있도록 도움을 줄 뿐 오히려 모든 버그를 방지할 수 있다는 믿음은 프로젝트의 진행 방식과 결과에 좋지 않은 영향을 미칠 수 있습니다. 테스트 코드 사용 이유는 더 안정적인 서비스를 만들 기회를 제공한다는 것입니다. 데브피플의 개발 방식을 통해 합리적인 가격으로 안정적인 서비스를 만들어보세요.
