Replies: 1 comment
-
저는 찬성합니다. 테스트 코드를 작성하는 번거로움을 감수하더라도 테스트 케이스에 맞추어 개발하면 안정성을 확보할 수 있을 것 같습니다! 또한 추후 CI/CD를 활용한 자동화 테스팅에도 활용할 수 있을 것으로 생각됩니다. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
TDD란?
소프트웨어 개발 방법론 중 하나로, 간단히 말해 "테스트 주도 개발"이라고 할 수 있습니다.
이 방법론은 소프트웨어 개발 과정에서 테스트 케이스를 먼저 작성한 후에 해당 테스트 케이스를 통과할 수 있는 코드를 작성하는 방법을 말합니다.
TDD 싸이클
TDD는 Red→ Green→ Refactor총 3단계의 구성으로 되어있고, 이러한 3단계를 반복하면서 코드를 점진적으로 개발하고 개선할 수 있습니다.
Red: 실패하는 테스트 케이스를 작성
위 테스트 코드는 실패하는 코드입니다.
Calculator
클래스를 아직 작성하지 않았기 때문입니다.Green: 테스트 케이스를 통과할 수 있는 최소한의 코드를 작성
Calculator
클래스를 구현할 때 최대한 빠르게 Green 단계에 도달하기 위해 변수가 아닌 상수를 반환하는 코드를 작성하고 점진적으로 변수로 바꾸어 나가는 것도 가능합니다. 위의 코드는 실제로 덧셈을 수행하지는 않지만, 테스트를 통과하기 위해 상수를 반환하는 코드를 작성하였습니다.Refactor: 작성된 코드를 리팩터링
위 코드는 테스트만 통과하기 위해 작성된 코드를 리팩터링 한 코드입니다. 이 단계에서는 Green단계에서 통과만을 위해 작성된 코드를 수습합니다.
TDD의 원칙
실패하는 단위 테스트를 작성할 때까지 프로덕션 코드(실제 사용자가 실행하는 소스 코드)를 작성하지 않습니다.
컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성합니다.
현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성합니다.
TDD의 장점
한번에 하나의 일만 집중할 수 있다
TDD 를 적용하지 않은 상황에서는 코드를 작성합니다, 다른 코드에 한눈이 팔리고, 다른 모듈을 건드리게 되다 보면 '내가 뭘 하고 있었더라?' 라는 생각이 들기 쉽습니다. TDD를 적용하면, 프로덕션 코드를 작성하며 현재 실패한 테스트 케이스를 통과하는 데에만 집중할 수 있습니다. 야크털 깎기 (Yak Shaving) 를 하지 않을 수 있습니다.
디버깅 시간의 단축
통합 테스팅이 아닌 유닛 테스팅을 하는 이점이기도 합니다. 우리는 각각의 모듈 별로 테스트를 자동화 할 수 있는 코드가 없다면 특정 버그를 찾기 위해서 모든 레벨의 코드들을 살펴봐야 합니다. 예를 들어 사용자의 데이터가 잘못 나온다면 DB의 문제인지, UI단의 문제인지 실제 모든 레이어들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있습니다.
테스트 코드 자체가 문서가 될 수 있다
TDD 를 적용하며 작성한 테스트 코드는 다른 관점에서 보면 '프로덕션 코드에 대한 요구사항' 입니다. 이는 테스트 코드 자체가 문서가 될 수 있음을 알려줍니다.
테스트를 나중에 작성하는 것은 귀찮다
프로덕션 코드를 작성한 상태에서 테스트 케이스를 작성하는 것은 귀찮습니다. 따라서 프로덕션 코드를 작성한 다음 테스트 케이스를 작성하게 되면, 프로덕션 코드에 맞춰 통과하는 테스트 케이스를 만들게 될 수 있습니다. 이렇게 되면 테스트 코드의 의미가 무색해질수도 있습니다.
재설계 시간의 단축
TDD는 테스트 코드를 먼저 작성하기 때문에 내가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 됩니다. 또한 테스트 시나리오를 작성하면서 다양한 예외상황에 대해 생각해 볼 수 있으며 이는 완성도 높은 설계로 이어집니다. 따라서 매우 크리티컬한 예외상황이 생길 확률이 극히 낮으며, 개발진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있습니다.
추가 구현의 용이함
개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드들에 어떤 영향을 미칠지 모른다는 점입니다. 따라서 단순한 기능이라도 추가 된 후에는 모든 기능들을 처음부터 테스트 해야합니다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전재하므로 이러한 테스트 기간 역시 획기적으로 단축 시킬 수 있습니다.
TDD의 단점
생산성의 저하
개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 합니다. 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문입니다.TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어납니다.
의견
생산성의 저하라는 단점이 치명적으로 다가올 수 있습니다. 기한이 짧게 선정된 프로젝트의 경우에서는 TDD를 적용하는 것이 큰 단점이 될 수 있습니다. 반면에 기한이 짧지 않은 경우에는 TDD의 도입하여 완성도 높은 코드를 작성하는 것이 좋을 것 같습니다. 저희 프로젝트의 경우 후자에 가깝다고 생각되어 TDD를 도입하여 완성도 높은 코드를 구현하려고 노력하는 것이 더욱 좋은 방향인 것 같습니다. 다른 팀원분들의 의견도 궁금합니다.
Beta Was this translation helpful? Give feedback.
All reactions