DevOps, TEST
데브옵스(DevOps)의 모델을 보면 계획 부터 모니터링에 이르는 사이클이 있다.
DevOps가 중요한 이유는 현재에 이르어서는 당연시 여겨지고 있기는 한데..
궁극적으로는 더 빠르고 안전하게(오류없이) 소프트웨어를 제공함이 목적이다.
이 중에서도 TEST에 관한 부분에 대한 약간.. 개인적인 의견이 들어간 고찰(?)을 해보자고 한다.
테스트, 테스트 피라미드
테스트의 종류는 크게 세가지로 나뉘어 진다.
유닛 테스트(Unit Test), 통합 테스트 (Integration Test), E2E (End To End Test)
각각 짧게 알아보자면,
- 유닛 테스트 (Unit Test)
유닛 테스트는 테스트 단계중 가장 작은 부분에 속하는데, 보통 작성한 함수가 정상적으로 돌아가는지를 테스트 하는 단계이다.
- 통합 테스트 (Integration Test)
단위 테스트 보다 더 큰 테스트 단계인데, 외부 라이브러리, DB에 접근하거나 전체 코드와 다양한 환경이 제대로 동작하는지 확인하는 테스트 단계 라고 볼 수 있다.
- E2E 테스트 (End To End Test)
애플리케이션의 흐름을 처음부터 끝까지 테스트 하는 것을 의미 한다.
실제 사용자의 시나리오, 애플리케이션 동작을 테스트 하는 단계이다.
테스트 피라미드는, 테스트 단계에 따라서 어느정도 비율로 테스트를 진행할 지에 대한 개념이다.
보통 유닛, 통합, E2E 의 비율을 6:3:1 정도로 하는게 가장 이상적.. 이라고 한다.
테스트 개발 방법론 TDD, BDD
테스트 개발 방법론에는 TDD, BDD 등이 존재한다.
- TDD (Test Driven Development)
테스트 주도 개발로, 테스트를 먼저 작성하고 이후 개발을 진행한다는 개념이다.
먼저 테스트 코드를 작성, 실행하고 테스트가 실패했으면 이에 따른 코드를 수정하고 개발을 진행하는 방식.
- BDD (Behavior Deriven Development)
TDD에 시나리오 테스트 까지 진행하는 방식.
요구사항에 집중해서 테스트 케이스를 만드는 방식.
https://www.mobilelive.ca/blog/value-of-tdd-bdd-ddd
Overcoming Complex Development: The Value of TDD Vs BDD Vs DDD
Tackling complex development with test, domain, and behaviour driven development. A comparison of BDD vs TDD Vs DDD and a look into the value at their intersection.
www.mobilelive.ca
대충 알겠어.. 근데 그래서 니가 뭘 할 수 있는데?
테스트 단계가 중요하다는건, 사실 누구나 다 알고 있다.
그런데, 현실적으로는 어떨까?
물론 인력이 충분하고, 인프라가 제대로 구축되어 있고, 시간적 여유도 충분한 상황에서 개발하고 있는 개발자라면 테스트모듈 잘 만들고 기획서 잘 보고 디자인 잘 보고 개발하고 테스트 하고 배포하고 할거다..
그런데 대부분은 꿈과 같은 얘기고, 프리랜서로 3년정도, SI로 5년정도 일을 해 본 결과
대부분의 클라이언트는 빠른 시간 내로 결과물이 나오는걸 원하고 그 기간은 보통 매우 짧은 편이며
또한 보통 아이디어만 가지고 있으며 그 아이디어가 뭔지 클라이언트도 잘 모른다는 것..이다.
(like 스무고개)
또 어느정도 규모가 있는 곳이 아니라면 기획쪽 파트도 부실하다.
받아본 기획서(?) 중에 가장 황당한건, 이 부분은 페이스북이랑 똑같이 진행해 주세요 ~ 라는 기획서.
~~랑 똑같이, ~~처럼 만들어주세요.. 라는 기획들이 굉장히 많다.
이게 기획자를 거쳐서 들어온..건데...
그러면 결국 해당 기획을 이해하려면, (기획자도 아마 모를거다, 그 기능이 어떤 기획을 가지고 있는지) 처음부터 끝까지 그 기능을 전부 써봐야 한다는 건데..
게임으로 예를 들면, '강화 시스템을 만들건데 ~~ 게임이랑 똑같이 만들어주세요~' 라고 넘어온다면, 진짜 그 게임의 종결까지 봐야지만 해당 강화 시스템을 이해 할 수 있을 것이다. 결국엔 그게 개발자 몫으로 오게 되는거고..
그러다 보니, 느낌상 한 7~80%의 프로젝트는 아래와 같은 흐름으로 흘러간다.
해당 케이스가 가장 많이 보이던 케이스인데,
클라이언트들은 보통 눈에 보이는 결과물을 원하고, 결국 SI에서 빠르게 수주하기 위해서라면 아이디어만 듣고 디자인을 먼저 뽑게 된다. 빠르게 눈에 보이니까.
요구사항 정의서 도입해 보자고 열심히 어필하고 시도도 해 봤지만, 다들 굉장한 자신감에 차 있는건지.. 글자로 된 문서는 잘 안 봐주더라..
근데 디자인 먼저 보여주면 보통 오~ 이쁘네요. 이렇게 가시죠! 하고 시작하게 된다.
그런데 아이디어만으로 나온 디자인에 제대로 된 로직이 있을리가 없다. 디자이너가 신도 아니고..
일단 토대로 설계하고, 개발을 진행하게 된다.
근데 이런 프로젝트가 동시에 4~5개가 돌아가게 되는데..
사실 그거보다 더 심한 케이스가 있으니, 디자인도, 기획도 없는 단계에서 바로 개발을 들어가야 하는 경우도 생긴다.
대충 아이디어만 듣고, 바로 개발을 진행해야 하는데 이걸 또 프로젝트 4~5개와 같이 병행한다..
보통 국가지원사업 프로젝트들의 통과용 프로젝트를 만들 때 이런 상황들이 많이 있던 것 같다.
(마감기간이 클라이언트의 마음도 아닌데, 발등에 불이 떨어져서 바로 착수 해야 되는 경우인 케이스 같다)
(잠깐 다른 얘기지만 그나마 모니터링은 기본 서버 로그와, 프레임워크 로그, AWS에서 기본적으로 지원하는 로그들로 추후 뭔가 오류가 발생하면 추적이 가능하다)
그러니 테스트 단계가 있을 수가 있나..
실제로 대부분 테스트 방법론의 단점으로는, 사전준비 기간과 테스트 모듈의 유지보수로 꼽힌다.
E2E 케이스의 경우에는 어느정도 규모가 되더라도 (QA팀이 있는 수준의 규모) 실제로 QA팀이 있다보니 배제하는 케이스도 있더라.
사실 위 케이스 대로라고 한다면, 테스트 단계 라는 것 자체가 굉장히 무의미 하기도 하다.
결국 비지니스단 부터 이해가 잘못 되었을 것이고 이미 개발이 산으로 가고 있을 가능성이 농후 하기 때문에...
그런 상황에서라도 지금 보면 Unit Test는 진행이 가능해 보이는데(일반적인 함수를 테스트 하기 때문에 프로젝트를 다시 시작하더라도 해당 함수는 쓰일 가능성이 크더라!), 초기 구축을 잘 해 둔다면 잘 사용 할 수 있지 않을까?
개인프로젝트만 진행하고 있는 지금 시간이 어느정도 남고, 개인적으로도 해보고 싶던 부분이라서 유용하고 편하게 유닛테스트를 진행하는 방법에 대해 고민해 보려고한다.
'DevOps' 카테고리의 다른 글
| [Postman] 쉽게 API 명세서 만들기 (0) | 2023.06.02 |
|---|---|
| 테스트에 관하여..(2) - 효율적인 테스트 케이스 관리는 어떻게 해야 할까? (굉장히 주관적인) (2) | 2023.05.08 |
| TypeScript에 jest를 적용해보자 (0) | 2023.05.08 |
| [Ansible] Ansible + git Action + EC2 자동배포 + IAM 보안 설정 (0) | 2023.04.27 |
| [gitAction] Ansible + gitAction을 이용한 EC2 자동배포 (0) | 2023.04.26 |
