[ Testing ] 테스트에 관하여: 배경, 내가 생각하는 테스트
테스트를 공부하게 된 배경
테스트는 중요하다는 것은 많은 사람들이 알고 있을 것이다. 그리고 이를 반영한 테스트 주도 개발(TDD; Test Driven Developement)와 같은 개발론도 존재한다. 하지만 생각보다 실제로 테스트 코드를 작성하고, 이를 활용하는 곳을 찾아보기 힘들었다. 테스트 코드를 왜 작성하지 않나요? 해당 기능이 정상 동작하는지 어떻게 확신할 수 있나요?, 신규기능 혹은 변경사항이 기존의 로직에 영향을 주는지 알 수 있나요? 등 다양한 의문점을 가질 수 있지만, 테스트 코드를 작성하면 개발 못한다 는 이야기를 많이 들어볼 수 있었다. 뿐만아니라 테스트코드는 작성도, 관리도 귀찮아지는 것이라고 생각하는 사람이 많았다.
그 사람들의 의견도 존중하지만, 나는 테스트를 통해 얻는 점이 더 많다고 생각한다. 그리고 매번 입아프게 반복해서 이야기하는 것이 힘들고, 스스로 테스트에 대한 공부를 진행하기 위해 테스트에 관하여 정리를 해보려고한다. 테스트란 무엇인가, 테스트를 작성하는 이유, 테스트를 작성하는 방법 등 전반적인 테스트에 대한 내용을 정리하고, 내 생각을 함께 작성해보고자 한다.
내가 생각하는 테스트
나는 수동으로 직접 테스트하는 것은 지양하고, 자동테스트를 지향해야 한다 생각한다. 수동 테스트는 비용이 많이 들면서 1회용에 가깝기 때문이다.(혹은 매번 엄청난 비용을 들여야한다.) 따라서 나는 몸 풀고, 손풀고 팔 걷고 하는(비장하게 수동으로 진행하는 테스트)가 아닌, 자동으로 이뤄지는 테스트를 진정한 테스트라고 생각한다.
테스트는 단 한가지의 목적(책임)을 가지고 있다. 바로 테스트를 통해 개발중인 메서드(행위)를 검증하는 것 이다. 그리고 이를 통해 해당 메서드를 이해하고 분석할 수 있게 된다.
뿐만아니라, 한번 정상적으로 동작하는 테스트를 작성함으로써, 신규기능 혹은 기존 기능의 수정이 발생했을 때 수정사항이 기존의 로직에 영향을 주는지 자동으로 확인할 수 있다. 단, 이를 위해 테스트는 메서드의 행위를 제대로 검증해야한다.
따라서, 내가 생각하는 테스트를 작성하는 이유는 다음과 같다.
- 개발중인(혹은 개발된) 메서드의 동작(행위)를 보다 쉽게 이해할 수 있다.
- 테스트를 문서로 활용할 수 있다.
- 신규 기능이 개발되거나 기존의 기능의 수정이 발생할 경우, 기존로직의 정상작동을 검증할 수 있다.
- 변경(리팩토링)을 쉽게 할 수 있다.
하지만 이런 테스트는 항상 신뢰를 줄 때에만 테스트의 가치가 존재한다는 것을 잊어서는 안된다. 그냥 테스트를 작성한다고, 테스트가 주는 이점을 갖을 수 없다.
나는 테스트의 신뢰를 깨트리는 것들에 대해 생각을 해보았다.
- 불규칙한 실패를 하는 불규칙한 테스트
- 구현 세부사항을 확인하는 테스트
- 광범위한 범위의 테스트
- 외부요인에 의존하는 테스트
- 하드코딩 된 값을 사용하는 테스트
나는 어떤 테스트가 좋은 테스트인지 정답이 없다 생각한다. 따라서, 정해진 답이 없는 답을 찾는 것보다는 명백한 오답을 피하는 것이 효율적이라 생각한다.
그리고 나는 내가 알고 있는 내용과 모르는 내용을 공부하여 테스팅에 관한 지식을 채워 나갈 것이다.