TDD ( Junit4 + Mokito + AssertJ ) 겉핥기 1

TDD ( Test Driven Development ) 

  내경험에 비춰보면 기본적으로 Water fall 방식의 소프트웨어 개발방식은 가장 오래되 가장 많이 사용하고 있는게 현실인것 같다. 

 SI 일들은 하면서 스파이럴 방식이라든가 에자일이라든가 ( 같은 이야기 같기도 하지만... ) 전혀 찾아볼수 없었고 아무래도 SI 란 일의 특성 상 공공기관일들이 대부분이였다. 

  대기업들과 일한다고해도  별다를바 없었다.  요구사항이 나오고 요구사항을 정의하는 사람들이 정의서를 만들어오면 그 어마 어마한 양의 출력물을 다같이 보면서 기획자들은 밤새 기획문서와 화면 정의서를 만들고  밤새만든 기획서와 정의서를 보며 개발자들은 API 연동서, 테이블정의서 , ERD 등등... 작성 하고  다 작성되면 개발 시작!!! 

디아블로2 헬게이트가 열리기 시작 ...  그리고 진절머리 나는 검수가 끝나면 !!

하... 하얗게 불태웠다... 

 그나마 경험했던 게임회사들 경우에는 에자일을 적극 도입하려는 곳도 있었고 아예 시도 조차 생각 못하는곳 등 다양 했다.  스타트업 경우는 기존적으로 규모가 작아서 water fall 이 맞아 보이지만 문제는 그 water fall 조차도 제대로 잘 이해 못하는 사람들이 많았다. 역시 모든 것은 case by case 랄까... 

( 경험 했던 회사 중에는 규모가 있음 에도 water fall 조차도 자기 멋대로 변형해서 사용하고 있었고 전혀 에자일에 대한 이해도가 없는 상태인데도 에자일이 좋으니 하자라는 단순한 무식한 경우도 있었다. ) 

 이런저런 개발환경을 경험하면서 프로젝트를 진행 하다보니 단위 테스트의 중요성은 항상 느끼면서 개발을 했던거 같다. 단위 테스트가 제대로 안될 경우 결국엔 나에게 모든 것들이 부메랑 처럼 돌아온다. 

QA 가 진행 되면 수많은 버그들이 그리고 개선사항들이 나에게 돌아오고 개선사항들이야 기획자가 기획에서 놓친 부분이라고 책임 전가(?) 한다 해도 버그는 내몫이다. 내 손으로 그 버그들을 만들었으니 할말이 없다. 

 문제는 알면서도 딱히 버그를 최소화 할 방법이 없었다 . 최선의 방법이라면 테스트를 더 많이 해보는것 ? 문제는 테스트를 더 많이 해도 문제가 생긴다. 나도 모르게 빌드 전에 입력한 오타 , 시스템 환경에 따른 버그 , 입력된 값이 특정 경우에만 오작동하는 문제 , 예상치 못하여 추가 하지 못한 validation  등등...

왜 내가 할땐 되는데 남이 하면 안되는 건가 ! 

 그러다 사고를 한번 거하게 쳤고 ( 개발하면서 사고 한번도 안치는게 더 어렵지 않을까 싶다. ) 

그리고 나에게 권유? 제안? 뭐 아무튼... 내 위에 분께서 하신 제안은 TDD 를 프로젝트에 적용해보는게 어떻겠 냐는 것 이다. ( 문제가 생기면 100% 개발자탓이라고 하는 분들때문에 나에게 거절할 기회가 없었다. )

TDD 는 글로만 봤지 쓰지도 쓸생각도 없었기에 난감했다. 

 테스트 코드들을 작성하여 로직들이 돌아가는 최소한의 안정성을 보장하기 위한 일종의 개발 방법론? 내가 이해하고 있는게 맞는지도 가물가물한 이 녀석을 해보라는거다. 

그래서 시작했다. 대충 R&D 만 2~3주,  개발은 생각보다 얼마 안걸렸다. 오히려 테스트케이스를 잡는 것이 더 어려웠다. 

- 테스트 테이스 산정 기준

  1. 테스트가 깨지는경우 ( 적용이 힘들어서 검증이 확실히 안되는 경우 )  최소화 

  2. 구축전이 아니라 이미 구축되어 서비스 되는 프로젝트에 대한 TDD 

  3. 실제 구현된 로직을 검증 해야하며 서비스에 영향이 있어선 안됨. 

  4. 웹페이지 기능들에 대한 검증이 필요 

얼추 내가 간추린 요구 사항은 이정도 였고 , 과연 이 조건들을 만족 시킬수 있는 것들이 얼마나 될지... 생전 TDD 안해본 능력부족 개발자의 고난길 시작 !!