유닛테스트의 작성빈도가 예전보다는 매우 높아지기는 했지만, 아직도 유닛테스트를 작성하기 “아까운” 부분이 있다는 생각이 완전히 바뀐것은 아니다. 이 생각의 원인을 찾기 위해 여러가지 장애물들을 생각해보았던 조각메모들..

유닛테스트와 소프트웨어 디자인

유닛테스트를 매우 중요시 하는 경우에, 대부분 유닛테스트가 소프트웨어 디자인을 개선시키므로 유닛테스트가 중요하다고 말하곤 한다. 사실 이 주장을 하기 위해서는,

• 좋은 소프트웨어 디자인이란 무엇인가

가 모두에게 정의되어야 한다. - 테스트하기 좋은 코드가 좋은 디자인이라는것에는 동의하지 못한다. 예를들면, 이벤트 시스템으로 모든 모듈을 설계하면 유닛테스트를 하기에는 쉽지만, 이벤트 발신에 따른 사이드 이팩트가 있을경우 추적하기 어렵기 때문에 “수정이 있을때 국수적이고 영향도에 확신이 있어야한다”를 좋은 소프트웨어 디자인이라고 생각하는 사람에게는, 이러한 디자인이 좋다고 받아들이기 힘들것이다.

이것은 TDD는 죽었는가의 Test-induced design damage에서 어느정도 다루고 있기도한데, TDD가 소프트웨어 디자인을 망친다는것은 좀 극단적이긴 하지만 유닛테스트 하기 좋은 구조가 무조건 좋은 디자인은 아니라는것에는 많은 사람들이 동의를 할 것이다.

따라서, 좋은 소프트웨어 설계를 위한 유닛테스트는 목적(좋은 소프트웨어 설계)에 비해 비용이 많이 들 수 있다.

유닛테스트와 비용

유닛테스트를 작성하는데 당연히 비용이 드는데, 이것을 상쇄할만한 장점이 있어야 한다. 내 결론으로 유닛테스트의 최대 장점은, 자신감을 얻는 코드 인것 같다. 따라서 이미 자신감에 차 있는 코드이거나 테스트를 짜더라도 자신감이 생기지 않을것 같은 경우 - 예를들면 로직 구현상의 문제라기보다 알지 못하는 예외처리에 의한 버그가 많을것으로 예상되는 경우 - 는 유닛테스트 작성 비용이 그에 따른 결과보다 더 크다고 생각한다.

유닛테스트와 버그

위의 내용과 연결되는데, 과연 유닛테스트는 버그를 많이 줄여줄까도 고민해 볼 필요가 있다. 참여했던 프로젝트의 주요 버그 발생 원인을 파악해본것도 사실 유닛테스트와 버그와의 관계가 궁금해서였을 정도이다.

결론은, 유닛테스트를 안했기 때문에 생겼던 버그보다는 그 외의 이유로 생겼던 버그가 많았다였고, 사실 어쩌면 당연한 결과일것이다. - 물론 버그는 줄어들지만, 그것이 유닛테스트로 인해 좀더 꼼꼼히 본 결과 때문인 경우가 많았고 유닛테스트가 아닌 다른 방식으로 꼼꼼히 봤다면 같은 결과에 도달했을 것이다.

다만, 유닛테스트를 통해 자신없는 부분의 코드에 대해서는 자신감이 생기기 때문에, 더 복잡하게 쌓아가거나 앞으로 나아가는데 잠재적인 버그는 더 적은것 같다.

유닛테스트와 소통

유닛테스트화 되어 있는 로직은 이야기 하거나 리뷰하기가 좋다. 사실 전체 코드에 대한 리뷰가 필요하다고 주장하는 경우에는 넓은 유닛테스트 커버리지의 필요성이 강조될 수 있을것이다. 다만, “노력을 더욱 해야하는 코드”가 존재하고 그것에 대한 코드리뷰를 해야한다는 입장이라면, 그부분에 대한 유닛테스트만으로도 소통하는데는 충분하다고 느낄수 있다.

TDD는 죽었는가

말잔치라는 소문때문에 TDD는 죽었는가를 주의깊게 살펴보지는 않았지만, 마틴파울러옹의 정리는 꽤 깔끔한거 같다. 한글로 된 번역글도 있으므로 유닛테스트에 대해 마음의 정리가 필요하신 분들을 일독하는것도 좋을것 같다.

결론

유닛테스트는 자신이 없는 부분에 대해서 조금씩 진행해나가는것도 괜찮은 방법인거 같다. 물론 유닛테스트를 하기위한 구조가 아니라면, 소프트웨어 디자인에 대해서 한번더 생각해보고 리팩토링 하는것이 바람직할것이다.