티스토리 뷰
소스 코드를 작성하는 문법을 프로그래밍 언어라고 부릅니다. 그리고 소프트웨어 개발은 소스 코드를 작성하여 진행됩니다. 언어는 문법만 지켜지면, 어떠한 방식으로 표현이 가능합니다. 그러므로, 같은 기능을 개발하더라도 작성된 소스코드의 형태는 다를 수 있습니다. 소스 코드가 올바르게 동작하는지 확인하기 위해 대부분 소프트웨어를 임시로 구동하여 결과를 눈으로 직접 확인할 것입니다. 그러나, 이러한 방법은 개발 속도를 느리게 할 뿐만 아니라, 테스트 실행 및 결과 확인에도 상당한 시간을 요구합니다. 테스트 코드를 이용하면, 개발을 빠르게 진행 가능하며 테스트도 손쉽게 수행할 수 있습니다. 이번 포스팅에서 단위 테스트의 정의, 장점, 특징을 알아보며 단위 테스트를 작성해야 하는 이유에 대해 알아보겠습니다.
단위 테스트 정의
단위 테스트는 특정 단위 모듈이 의도대로 정확히 작동하는지 검사하는 절차를 말합니다. 영어로 단위 테스트는 Unit Test라고 정의합니다. 단위 테스트를 작성할 때, 3A 구조를 지켜서 작성하면 단위 테스트 코드 구조가 명확해집니다. 3A란 Arrange, Act, Assert의 3개를 뜻합니다. Arrange는 테스트할 클래스의 객체 생성 준비단계, Act는 객체의 행위 실행 단계, Assert는 행위 실행에 대한 예측 결과 단계를 뜻합니다. 최근 대부분의 프로그래밍 언어는 단위 테스트 프레임워크를 지원하고 있습니다. 아래 이미지는 Java 언어로 작성된 단위 테스트 코드이며, 단위 테스트 프레임워크는 JUnit을 활용한 케이스입니다.
제품의 안정장치 역할을 하는 테스트 코드
단위 테스트 코드는 소스 코드의 입력과 출력을 검증하는 역할을 합니다. 실제 제품의 기능을 수정하였을 경우, 제품을 출시하기 이전에 결함을 조기에 발견할 수 있습니다. 프로그래머는 코드를 수정한 후 , 적절한 테스트가 이루어지지 않고 제품을 출시할 경우 불안감을 겪게 됩니다. 제품의 기능을 수정한 후 테스트 코드로 기능 검증 결과를 손쉽고 빠르게 확인한다면, 소스 코드를 수정하는데 높은 자신감을 갖고 개발업무를 수행할 수 있습니다.
테스트코드 작성 원칙
단위 테스트 코드는 가능하면 간결하고 읽기 쉽게 작성하는 게 좋습니다. 어떠한 의도로 기능 검증을 수행하는지 의도가 드러나는 것이 좋습니다. 단위 테스트는 10줄 이하로 작성하고, 단위 테스트 코드는 단일 기능을 검증하는 것이 좋습니다. 하나의 테스트 코드에서 여러 가지 기능을 검증하는 코드를 작성하면, 오류가 발생한 지점 이후의 테스트는 진행되지 않습니다. 그러므로, 테스트 코드는 가능하다면 독립적으로 실행될 수 있는 구조로 작성하는 것이 좋습니다. 단위 테스트는 5가지 원칙을 준수한다면, 올바르게 작성된 단위 테스트라고 볼 수 있습니다.
- Fast : 빠르게 실행되어야 한다
- Isolated : 각 테스트는 독립적으로 실행되어야 한다.
- Repeatable : 매번 실행 결과는 동일해야 한다,
- Self-Verifying : 결과는 Pass or Fail 둘 중 하나의 상태 값을 가진다.
- Timely : 비즈니스 로직 코드 작성보다 테스트 코드를 먼저 작성한다.
단위 테스트의 장점
단위 테스트를 활용하면 얻을 수 있는 장점은 아래와 같습니다.
- 프로그램의 안정성 향상된다.
- 디버깅 시간을 단축할 수 있다.
- 상시 제품의 소스 코드를 수정하는데 자신감을 가질 수 있다.
- 제품의 기능을 통합할 때, 문제를 빠르게 발견할 수 있다.
- 기능 사용에 대한 성공 또는 실패에 해당하는 피드백을 빠르게 받을 수 있다
개발자들이 테스트 코드를 작성하지 않은 이유
단위 테스트를 작성하면 얻을 수 있는 장점이 있음에도 불구하고, 많은 사람들이 테스트 코드를 작성하지 않은 이유는 무엇일까요? 가장 큰 이유 중에 하나는 IT 개발자들의 인식입니다. 개발자들의 여러 가지 의견을 살펴보면, 아래와 같은 인식을 가진 개발자들이 많습니다.
- 개발자는 제품의 기능을 코드 구현하는 것 주요 업무이지, 코드를 테스트하는 것은 업무가 아닙니다.
- 테스트 코드를 작성할 시간이 없습니다.
- 코드가 어떻게 동작해야 할지 정확히 모르는데 어떻게 테스트해야 할지 모르겠습니다.
- QA팀이나 테스터의 일을 빼앗는 것이라고 생각합니다.
위와 같은 의견에 대해 반론을 하자면, 제대로 동작하는 코드인지 확인하려면, 단위 테스트가 반드시 필요합니다. 테스트 코드 작성하는데 드는 시간은 많이 소요되지 않습니다. 테스트 코드는 함수 호출 후 기대 값과 실제 값 비교만 하면 됩니다. 그리고, 개발자가 코드가 어떻게 동작해야 할지 알지 못하므로 어떻게 테스트해야 할지 모른다는 것은 요구사항을 제대로 이해하지 못한 상태로 기능을 개발한 것이라고 볼 수 있습니다. QA팀은 기능 및 인수 테스트, 유효성 검증 등 할 일이 많으므로, 단위 테스트까지 담당하는 것은 QA가 할 일이 아닙니다.
개발자는 제품의 기능을 개발하는 것이 본인의 역할이라고 생각합니다. 제품 출시 이전에 테스는 누가 하는 것일까요? 개발자들은 대부분 QA 파트 담당자가 수행하는 것이라고 생각할 것입니다. 하지만, 이는 잘못된 생각일 가능성이 높습니다. QA는 출시된 제품의 품질을 높이기 위한 활동과 프로세스를 수립하는 역할입니다. 즉, QA는 출시되기 직전의 제품을 검증하는 담당자입니다. 개발자는 본인이 구현한 기능에 대한 최소 기능 테스트는 진행해야 합니다.
마치며
단위 테스트 작성해야 하는 이유를 통해 개발자들의 역할에 대해 잠깐 살펴본 결과, 개발자들이 해야 할 일은 정말 많습니다. 요구사항을 이해하고, 모호한 요구사항을 구체화하는 작업까지도 진행해야 합니다. 기능을 개발할 뿐만 아니라, 기능의 단위 테스트 코드도 작성해야 하고, 급변하는 IT 기술 트렌드 동향까지도 파악해야 하므로 IT 역량개발도 꾸준히 진행해야 합니다. 그리고 다른 부서와도 커뮤니케이션도 진행해야 하므로, 예전에는 3D업종으로 불릴 정도로 기피하는 직업이었습니다. 이러한 업무 강도에 비해 대우는 좋지 않았습니다. 한국 사회는 제조업을 중시하고, 성과를 인정해주기 때문에 IT업계에 종사하는 근로자들은 사회적 인식이 좋지 못하였죠. 하지만, 최근 코로나 인해 IT 기술을 활용한 비대면 서비스가 증가하고, 비대면 서비스의 수요가 폭발적으로 증가하여 IT 개발자들의 연봉과 대우가 급격하게 상승하였습니다. IT 개발은 건축업무와 매우 유사한 점이 많습니다. 기초 뼈대 설계와 공사를 잘 진행해두면, 태풍이 몰아쳐도 버틸 수 있습니다. 기능 수정으로 인해 제품의 오류를 출시 이전에 발견하여, 폭풍을 미리 막을 수 있으므로, 테스트 코드를 작성하는 습관을 만들어 나가는 게 좋을 것 같습니다.
'IT 기술' 카테고리의 다른 글
[Node.js] 설치 및 서버-클라이언트 예제 작성하기 (0) | 2022.09.13 |
---|---|
JUnit 기반 Java 테스트 코드 작성방법 (1) | 2022.09.13 |
CNN, R-CNN, Faster R-CNN의 특징 (0) | 2022.09.07 |
Deep Learning CNN 설계방법 (0) | 2022.09.07 |
Tensorflow Object Detection API 사용하기(Ubuntu 16.04) (0) | 2022.09.07 |
- Total
- Today
- Yesterday
- notion 업무일정관리
- token
- SPA
- 스프링부트 restapi
- iframe 태그 찾기
- 디자인패턴
- 멀티코어 멀티프로세서
- oracle 메모리
- 스프링부트빌드
- 클린코드작성원칙
- 디자인패턴 구조패턴
- TCP/UDP
- C++
- 클린코드작성법
- 테스팅 자동화
- MPA
- selenium
- springboot restapi
- springboot 실행
- API Gateway 캐싱
- python
- OSI 7계층
- 스프링부트실행
- springboot build
- notion
- oracle pga sga
- codesmell 유형
- 코드스멜 유형
- AWS
- springboot rest api 서버
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |