이번 여름 방학동안 DND 6기에서 개발했던 프로젝트 '흐릿'을
함께 했던 팀원분과 리팩터링하는 시간을 갖기로 하였다.
그리고 주어진 시간에 쫓겨 테스트 코드를 작성하지 못하였던 것이 후회되어
테스트 방법론을 학습하고 적용하여 다시 디벨롭 해보려고 하였기에 테스트 방법론에 대하여 공부하고 기록하게 되었다.
테스트 코드를 작성해야하는 이유
우선 테스트 코드를 작성하고자 하는 이유에 대해서 짚고 넘어가겠다.
"자동화된 테스트 환경을 구축한다."
기능이 추가 또는 변경되면 애플리케이션을 재시작 후 Postman 등을 통해 일일히 기능을 실행해보며 확인하지 않아도
테스트코드를 실행하기만 하면 기능이 정상적으로 작동하는지 짧게는 몇 초만에 확인할 수 있다.
"기능에 결함이 있다면 사전에 발견할 수 있다."
만약 2020년 이상부터 2030년 이하의 데이터들을 조회하는 로직을 구현해야한다고 가정해보자.
이때 내가 만약 2030년 이하가 아닌 미만의 데이터를 조회하도록 로직을 잘못 작성했다고 했을 때,
이는 컴파일 시점에서 잡을 수 없을 뿐더러 정확히 확인하지 못한 경우 기능적 결함으로 이어질 수 있다.
하지만 2030년 까지의 정보를 제대로 조회해오는 지 검증하는 테스트 코드가 있다면 그러한 결함을 사전에 발견하여 조치할 수 있을 것이다.
"코드 작성자의 의도, 사용법 등이 드러난 프로젝트에 대한 문서로서 작용할 수 있다."
보통 '~하면 예외가 발생한다' 등 다양한 상황에 대해 테스트 코드를 작성하는데
이는 코드를 처음 보는 이들에게 있어 일종의 문서로서 작용할 수 있다.
크기가 어느정도 있는 프로젝트를 클래스 하나하나 전체적으로 흝어보기 전에
각 기능의 테스트를 살펴보면서 어떤 상황에서 어떻게 동작하는 지를 파악한다면
전체적인 코드의 흐름을 이해하는 것이 조금 더 수월해질 것이다.
애자일 방법론?
테스트 방법론을 공부하는 과정에서 들어는 봤지만 정확히 뭘 뜻하는 지는 몰랐던 에자일 방법론이 자주 거론되어서
간략하게 알아보았다.
애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
= 공정과 도구보다 개인과 상호작용을 =
= 포괄적인 문서보다 작동하는 소프트웨어를 =
= 계약 협상보다 고객과의 협력을 =
= 계획을 따르기보다 변화에 대응하기를 =
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
| Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만,
본 고지와 함께 전문으로서만 가능하다.
위는 번역된 애자일 선언문이며 애자일 방법론이 추구하는 바를 알 수 있다.
정해진 계획과 문서에 의존하여 a,b,c,d 순으로 개발을 진행해나가는 것이 아니라
미래를 예측하기 보다는 주기적으로 제작 프로토타입을 시험해보는 철저한 관리를 통한 개발 방법론이라 할 수 있으며 끊임없이 개발하고 수정하는 일을 반복하면서 고객이 가장 만족할 수 있는 방향으로 소프트웨어를 개발한다.
요약하면 컴퓨팅 환경과 시대가 변화함에 따라 계획 중심적이며 유연함이 없는 기존 폭포수 모형 개발론 방식(Waterfall Model) 방식은 한계점이 명확히 드러났고, 한계를 극복하기 위해 개발과 함께 즉시 피드백을 받아 유동적으로 개발하도록 만들어진 방법론이 바로 애자일 방법론이다.
폭포수 모형 개발론
1970년에 창안된 소프트웨어 개발 프로세스로 각 단계가 마치 폭포처럼 위에서 아래로 물이 떨어지듯이 차례대로 진행되어 붙여진 이름이다.
여러 단계가 병행되거나 거꾸로 진행되는 경우는 거의 없다. 일정 생명주기를 반복하는 애자일과는 반대되는 개념이다.
폭포수 모형 개발론은 지나치게 계획에 의존하고 있으며 형식적인 절차를 따르기 때문에 시간도 오래걸리고 그 효율성이 크게 저하된다는 단점이 있다.
하지만 사실 이 글을 쓰고 있는 나는 현업경험이 없어서인지 폭포수 모형 개발론의 단점이 와닿지는 않았다.
오히려 진행했던 프로젝트들이 전부 '폭포수 모형 개발론'을 따랐고 아직 큰 문제나 불편을 느껴보진 못했다.
애자일을 차용하는 팀들의 의견을 찾아보면 '유연함', '생산성', '고객만족', '개발속도' 등의 이점을 찾아볼 수 있었는데,
현업 또는 큰 팀에서 일하고 있지 않은 사람 기준에서는 이해하거나 공감하기 어려운 내용이라고 생각이 들었다.
만약 나와 같은 생각과 상황을 가진 상태로 글을 읽으면서 "나는 애자일이라는 것에 대해 공감이 안 되는데, 내가 이상한 걸까?" 라는 생각이 들었다면 이상한게 아니라 그게 정상일 것이다.
애자일에서 파생된 테스트 방법론
앞서서 애자일에 대해서 간략하게 알아보았는데, 테스트 얘기하다가 갑자기 웬 애자일? 이라고 생각하는 사람도 있을 것이다.
나도 처음에 그렇게 생각했었는데, TDD, BDD 라는 아주 유명하고 대표적인 테스트 방법론이 애자일에서 파생되었다고 한다.
때문에 TDD, BDD를 설명하기 전에 애자일에 대해서도 짧게 알아보고 넘어간 것이다.
이제 이번 글의 핵심이자 내가 궁금했던 내용인 TDD, BDD에 대해서 알아볼 것이다.
TDD (Test-driven development)
TDD는 말 그대로 테스트 주도 개발을 의미한다.
테스트가 이끌어나가는 개발 환경을 표현할때 사용되며
쉽게 말해 실제 구현 코드를 작성하기 전에 테스트 코드부터 작성하는 방식이라는 것이다.
"선 테스트, 후 구현"
이것이 TDD가 뜻하는 바이다.
TDD 방법론의 개발방식
1. 요구사항을 검증하는 테스트 케이스 작성
- 이때 테스트가 실패하더라도 알아볼 수 있고 컴파일만 가능하게 테스트 코드를 작성하면 된다.
2. 테스트 케이스 통과하기 위한 최소한의 코드 생성
3. 최종적으로 작성한 코드를 기준으로 표준에 맞게 리팩토링
장점
- 코드의 확장성 및 유지보수 용이 (코드의 모듈화가 자연스럽게 이루어짐)
- 프로그램 소스코드 기록 (테스트 코드로 인해서 코드의 목적성과 과정을 기록하는 효과)
- 총소유비용(TCO) 절감
단점
- 숙련되기까지 다소 시간이 소요된다.
- 선행 투자가 많이 필요하다.
BDD (Behavior-driven development)
BDD는 행위 주도 개발로 해석할 수 있다.
기본적으로 TDD에 기반을 두고 있으며 큰 차이가 나지 않는 것 처럼 보일 수 있지만,
BDD는 TDD에서 한 발 더 나아가 테스트 케이스자체가 요구 사양이 되도록 개발하는 방식이다.
TDD는 테스트 단위가 함수 단위로 매우 작아서 작성하는 대부분의 함수가 테스트 대상에 포함되기 때문에 현업에서 사용하기에는 다소 번거로움이 느껴질 수도 있다.
그래서 TDD에서 파생되어 등장한 BDD는 함수 단위의 테스트를 권장하지 않고 시나리오 기반의 테스트 케이스를 작성한다.
이때 이 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있을 정도여야 한다.
(자연어같아야 한다)
시나리오는
Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장한다.
장점
- 비지니스에서 요구하는 가치를 제공
- 다른 커뮤니티 구성원들도 참여할 수 있다.
(프로그래머뿐만 아니라 전 구성원이 이해와 협의할 수 있다는 점에서 TDD 보다 좀 더 애자일스러움)
단점
- BDD를 지원하는 소프트웨어 툴은 비교적 적다.
TDD와 BDD 의 차이
TDD는 개발코드의 완성이 목적
BDD는 개발 결과의 검증이 목적
조그마한 개발팀에 있고 일하는 대상이 모두 개발자라면 굳이 BDD를 사용할 필요가 없을 수도 있다.
반대로 다양한 직군의 팀원들이 이해할 수 있는 시나리오 바탕의 테스트를 작성해야한다면 BDD를 선택하는 게 좋은 선택일 수 있다.
TDD는 코드 자체에 집중한 테스크 코드 작성을 중시하고
BDD는 프로그래머가 아닌 구성원들도 함께 검증하고 소통하여 의견을 반영해나가는 방식이기 때문이다.
결론적으로 차이점에 대한 설명과 함께 하고싶은 말은,
기술에 무조건적으로 좋은 것은 없으며 모든 기술은 트레이드 오프가 있고 상황에 따라 더 좋은 방식을 선택하라는 것이다.
요구사항과 환경에 따라 필요한 기술을 선택할 줄 아는 지식을 기르고,
필요한 시점에 올바른 기술을 적용할 줄 아는 개발자가 되는 것을 목표로 하자.
reference
'BackEnd' 카테고리의 다른 글
| 테스트를 위한 객체, 테스트 더블(Test Double) (0) | 2024.04.04 |
|---|---|
| [인증/인가] RefreshToken은 왜 Redis를 사용해 관리할까? (with. RTR 방식) (5) | 2023.06.13 |
| WAS(Web Application Server)란 무엇인가 (0) | 2023.01.02 |
| 포스트맨(Postman) 사용해서 카카오 엑세스 토큰 받기! (1) | 2022.02.10 |
| [포트포워딩] LG U+ 공유기 (0) | 2021.12.02 |