오늘 날 소프트웨어는 빅데이터, IoT, 인공지능 등의 다양한 분야로 발전하고 있으며, 소프트웨어는 냉장고, 세탁기, TV 등과 같은 백색가전뿐만 아니라 컴퓨터, 핸드폰 등 우리 실생활의 많은 부분에서 사용되고 있다. 소프트웨어는 실생활뿐만 아니라 비행기, 철도, 자동차 등 결함 발생 시 큰 인명피해로 이어질 수 있는 분야에도 광범위하게 사용되고 있다. 따라서 기능뿐만 아니라 안전성까지 보장되는 고품질의 좋은 소프트웨어를 개발해야 한다. 좋은 소프트웨어가 만들어지기 위해서는 잘 동작하고, 결함이 없고, 유지보수가 쉬워야 한다. 그러나 좋은 소프트웨어를 만들기란 고려해야 하는 요소들이 다양하고, 그 종류가 많기 때문에 매우 어려운 작업이다. 하지만 소프트웨어가 나온 지 60여 년이 넘는 현재, 좋은 소프트웨어를 개발하기 위한 소프트웨어 개발 방법들이 많이 존재하며, 본고에서는 그 중에서 테스트와 개발을 같이 진행하여 개발 초기의 오류를 발견하고, 수정하여 좋은 소프트웨어를 개발하기 위한 테스트 주도 개발(TDD, Test Driven Development)방법에 대해 이야기하고자 한다.

 

 

TDD의 정의

  • Test Driven Development
    • 테스트 주도 개발: 테스트가 개발을 이끌어 나간다.

구체적인 행동 레벨에서의 TDD의 개념

테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것 즉, 만드는 과정에서 우선 테스트를 작성하고 그걸 통과하는 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것이다.

 

  • 보통은 SW 개발을 할 때 코딩을 다 끝나고 난 후 테스트를 한다.
    • 코딩이 끝난 후? 개발자가 코딩을 다 짜고 난 후 완성했다고 생각할 때
    • 이것의 순서를 바꾸는 것이 TDD를 적용하는 것이다.
  • TDD를 적용한 사례
    • 예를 들어, 생년월일(input)을 입력받으면 현재 나이(output)를 출력하는 프로그램
    1. 처음에는 간단한 것으로 목표를 정한다. (태어난 해와 올해의 연도를 입력)
      • 2015, 2018 -> (만)3살 우선 이것을 만들겠다는 생각을 한다.
    2. 만들기도 전에 만든 후에 무엇을 테스트할지를 설계한다.
      • 2015, 2018를 입력하면 2가 나오는 테스트 프로그램(장차 만들 프로그램을 테스트할 코드)를 만든다.
    3. 그 다음에 그 테스트를 통과할 프로그램(1.을 목표로 작성한 코드)를 만든다.
      • 올해의 연도 - 태어난 해
      • 2018 - 2015
    4. 테스트 프로그램으로 이 프로그램(3.에 해당하는 코드)을 실행한다.
    5. 통과했으면 새로운 테스트를 추가한다.
      • 이번에는 생월을 추가했을 때 계산하는 프로그램
    • 위와 같은 작업을 계속 왔다갔다 수행한다.

추상적인 레벨에서의 TDD의 핵심 개념(중요)

결정과 피드백 사이의 갭에 대한 인식, 더 나아가 결정과 피드백 사이의 갭을 조절하기 위한 테크닉이라고도 할 수 있다.

  • 켄트 벡(Kent Beck, 익스트림 프로그래밍의 창시자)
    • TDD란?
      1. 결정과 피드백 사이의 갭에 대한 인식
      2. 결정과 피드백 사이의 갭을 조절하기 위한 테크닉
    • TDD는 프로그래밍 기법이나 기술적인 느낌보다는 심리적인 것으로 볼 수 있다.
  • 결정(decision)?
    • 프로그램을 하다보면 ‘이 방법으로 해야지’, ‘이 부분은 이걸 이용해서 짜야지’라는 것을 결정한다.
  • 피드백(feedback)?
    • 프로그램을 하다보면 성공/실패(에러)라는 피드백을 받는다.

이 둘(결정과 피드백) 사이에 갭이 생긴다.

  • 갭이 커질수록 문제!
  • 내가 그 갭을 모르면 더 큰 문제!
  • 즉, 위의 예와 함께 설명하자면
    • 결정: 1.을 목표로 코드를 작성할 때, ‘나는 빼기로 나이를 구해야겠다.’라는 것을 결정한다.
    • 피드백: 빼기로 계산했을 때의 코드를 테스트 프로그램을 실행한 결과로, 된다/안된다라는 프로그램 상의 피드백을 받는다.
    • 이 둘 사이의 갭을 내가 인식한다면 TDD를 하고 있는 것이다.

 

TDD는 작가가 책을 쓰는 과정과 유사하다. 책을 쓸 때는 목차를 처음 구성한다. 이후 각 목차에 맞는 내용을 구상하여 초안을 작성하고 고쳐쓰기를 반복한다. 이 과정을 TDD에 비유하면 목차구성은 "테스트코드 작성", 초안작성은 "코드개발", 고쳐쓰기는 "코드수정"에 해당한다. 반복적인 검토와 고쳐쓰기를 통해서 좋은 글이 완성되는 것처럼 소프트웨어도 반복적인 테스트와 수정을 통해서 고품질의 소프트웨어를 만들 수 있다.

 

 

TDD 장점

- 작업과 동시에 테스트를 진행함으로써 실시간으로 오류 상황을 파악하여 시스템 결함을 방지

- 짧은 개발 주기를 통해 고객의 요구사항을 빠르게 수용하거나 피드백을 줄 수 있고 현재 진행 상황을 쉽게 파악

- 자동화 도구를 이용해 TDD의 테스트케이스를 단위테스트로 사용이 가능

테스트 자동화 도구는 Junit(Java), CppUnit(C/C++), NUnit(.NET) 등이 있음

 

TDD 단점

- 기존의 개발프로세스에 테스트케이스 설계까지 추가되므로 코드 생산 비용이 높아짐

- 어떻게 테스트를 할 것이며, 프로젝트 성격에 따른 테스트 프레임워크 선택 등 여러 부분에 대한 고려가 필요

 

 

참조:

 

m.blog.naver.com/suresofttech/221569611618

 

gmlwjd9405.github.io/2018/06/03/agile-tdd.html

반응형

+ Recent posts