CS/소프트웨어 공학

Test-Driven Development (TDD)

hojak99 2016. 7. 23. 20:20

Test-Driven Development 란??


Test-Driven Development는 너무 길기 때문에 짧게 TDD라고 말하겠다.



TDD에 대해서 Lean 소프트웨어 개발론에 대해서 말하는데  이 개발론의 핵심 철학이 몇 가지 있는데 그 중 하나가 "결함은 발견 즉시 해결!"이다. Lean 개발은 이 "결함은 발견 즉시 해결"이라는 것에 대한 실천법으로 테스트 주도 개발, Test-Driven Development를 제시했다. 


TDD는 반복 테스트를 이용한 소프트웨어 개발법인데 이 TDD는 테스트 코드를 먼저 작성하고 실제 기능을 구현하는 코드는 나중에 만든다. wikidocs에서는 이것의 예로 건물을 지을 때를 들었다. 건물을 지을 때 벽돌을 쌓는 방법을 떠올리면 벽돌을 쌓을 때는 벽돌을 얼마만큼 쌓을 건지 표시를 하고 표시를 한 곳까지 벽돌을 쌓으면  쌓는 것을 중지하는 것을 예로 들었는데 이것을 TDD로 비유하면 얼마만큼 쌓을 것인지 표시하는 것을 "테스트 코드", 실제로 벽돌을 쌓는 것을 "실제 코드"에 비유할 수 있다.


이 예를 보면 알 수 있듯이 TDD의 목표는 작동하는 깔끔한 코드이다.  즉 이것을 자세하게 말하자면 코드가 단순하다는 의미가 아닌 중복이 없고 어느 개발자가 보아도 명확한 코드를 말한다. 


TDD는 테스트 케이스를 생성하는데 테스트 케이스는 자동화된 테스트 도구로 이용되어, 코드가 변경될 시에 기능이 제대로 작동하는지 쉽게 확인할 수 있다. 


TDD에는 흐름이 있는데 일반적인 흐름으로는 


[그림 1] TDD의 흐름

출처 : wikidocs.net


1. 무엇을 테스트할 것인가를 생각

2. 실패하는 테스트를 작성

3. 테스트를 통과하는 코드 작성

4. 코드 리펙토링

5. 구현해야 할 것이 있을 때까지 위 작업 반복




이제 TDD로 개발하는 방법에 대해서 알아보자.


TDD는 위에서 처럼 실패하는 테스트를 만들어야한다. 그리고 테스트를 통과하는 코드를 그 다음에는 테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고, 불명확한 것을 명확히 하는 리펙토링 단계를 거쳐야한다.


(TDD로 개발하는 방법에 대한 예시는 혼자 열심히 알아보길 바란다. 직접 코드를 작성하는 것을 추천하고 https://wikidocs.net/224 이 링크에 TDD를 쉽게 이해할 수 있는 예제와 그 코드, 코드에 대한 설명이 나와있고 필자도 역시 wikidocs 에 나온 것으로 실제 코딩을 했다. 직접 코드를 짜니 그래도 이해가 전보다 더 잘된 것 같음)




TDD의 장점은

1. 개발자가 자신의 개발 내용 및 진척 상황을 항상 살펴볼 수 있도록 해준다.

2 깔끔한 코드를 유지 가능하기 때문에 품질 높은 소프프트웨어 개발 가능

3. 자동화된 단위 테스트 케이스로 인해 시스템의 이상을 바로 확인할 수 있음

4. 테스트 코드를 작성하고 실제 코드를 작성하면서 더 많이 설계에 대해서 고민을 할 수 있기 때문에 설계가 좋다.




[이 TDD에 대해서 알게되고 사수님께 약간의 설명을 들었을 때는 '테스트 코드를 작성하고 실제 코드를 작성하는 방법이라고? 그게 가능한가? 테스트 코드란 것이 뭐지..?' 라는 생각을 했다. 그렇기 때문에 이 TDD에 대해서 조금 관심을 가지게 되었고 구글링을 통해서 TDD에 대해 글을 작성해놓은 사이트를 돌아다니면서 이해를 하기 위해 노력했지만 노력이 이렇다!고 할 정도로 되진 않았다. 몇 시간동안 이것에 대해서 생각해보고 이해하려고 노력한다고 해서 이해가 되는 것이라는 것을 알지만 그래도 이런 노력으로 인해 다른 사람에게 TDD에 대해서 이야기할 때 TDD란 ~란 개발 방법론이다. 라고 할 수 있을 정도는 되었으니 만족하는데 만족에서 끝내고 싶지는 않다.]


무척 간단하게 설명함. 



반응형