테스트를 못짜는 사람의 비겁한 변명 – Effective Unit Testing

이 책을 읽으면서 느낀 생각이지만, 내가 하고 있는 말이 “테스트를 못짜는 사람의 비겁한 변명”이 아닐까라는 생각이 들었다. 사실 안드로이드 개발을 하면서, “테스트를 만드는 것이 굉장히 힘든 일”이라고 생각하게 되었고(솔직하게는, 원래 테스트에 약한?) 거기에 대해서 계속 어려움을 격지만, 무시하고 넘어가고 있었다.

책을 보면서 내내 들었던 또 다른 생각중에 하나는 내가 하고 있는 실수들이 대부분 예시에 등장한다는 것이다. 중간에 나왔던, “주석으로 변한 테스트”의 경우, 구조의 변경이나, 해당 기능의 변경등으로, 필요없는 코드나, 테스트들을 단순히 주석처리만 해두는 경우가 많다. 그런데 사실 이런 경우는 큰 문제는 안되지만… 문제가 되는 케이스는, 그 테스트가 필요없어서가 아니라, 지금 구조에 맞게 테스트 하는 방법을 몰라서 그냥 “주석” 처리하는 것이 가장 나쁜 예가 아닐까 싶다.

또한 항상 어려움을 겪는, 테스트명을 제대로 작성하지 않는다라든지… 나의 가슴에 송곳처럼 찌르는 내용들이 꽤 많았다.(전부 나의 잘못!!!)

– 특정 조건일때만 검사가 되는 조건부 테스트라든지…
– 절대 실패하지 않는 테스트라든지…
– 아주 단순한 결과만 체크한다든지…
– 과잉 보호 테스트라든지…

그리고 테스트를 작성하면, 클래스의 인터페이스등이 그냥 생각하고 짤 때보다 훨씬 실용적이 된다고 할까?, 테스트를 잘 만들기 위해서는 인터페이스의 전달이라든지, 파라매터의 전달이 훨씬 깔끔해지는 것도 사실이다.

또한, 테스트는 좋은 샘플로의 가치도 있다. 함수의 사용법이나, 이런게 어려울 때, 테스트 코드가 많으면, 이를 어떻게 써야하는지 알 수 있는 경우가 많다.(나도 이렇게 만들어야 하는데…)

다만, 책을 읽는 분들이, “유닛 테스트”가 전부라는 생각은 안하는 것이 좋지 않을까 싶다. “유닛 테스트”를 만들면 모든 버그가 사라지는 것은 아니다. “테스트”라는 것의 개발자의 사고에 의해서 그 범위가 제한 당하기 때문에, 모든 케이스를 생각해서 테스트를 만드는 것은 어렵다. 다만, 어느 정도 제대로 된 테스트 셋이 있으면, “리그레이션 테스트”로써 상당히 많은 도움을 줄 수 있다라고 할 수 있다는…

전에서 팀에 한분이 거의 대부분에 대한 “외부 테스트”를 만들어 주셨고, 이를 통해서, 코드 전체가 바뀜에도 거의 큰 문제 없이(도리어 이걸 만들면서 이전의 케케묵은 버그들을 찾을 수 있었다는) 넘어갈 수도 있었다.

특히, 주변의 얘기를 들어보면, DBMS 같은 경우 그 테스트셋이 상당히 중요한 가치가 있다고 한다.

횡설 수설 했지만, 읽으면서, 새해에는 테스트를 이래이래해서 못짰습니다라는 비겁한 변명은 하지 않아야 겠다라는 생각이든다.(흑흑흑 안드로이드 테스트는 어떻게 헤야할까?)

About these ads

One comment on “테스트를 못짜는 사람의 비겁한 변명 – Effective Unit Testing

  1. 저도 프로젝트 진행하면서 늘 바쁘다 보니 테스트 케이스들은 뒷전엔데, 이 글을 읽고 느껴지는게 많네요. 늘 좋은 글들 감사드립니다. :-)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s