코드를 구현한 후에는 코드가 의도에 맞게 작동하는지 검증이 필요할 것이다. 지금껏 테스팅이 필요할 것이고, 현업에서도 테스팅이 자주 일어날 것으로 예상했었다. 하지만 현업에 계신 분들은 테스트 케이스를 만든 적이 거의 없고, '비효율적이다' 라는 이야기를 많이 하셨다. 이에 여러 테스트 방법을 알아보고 각각의 장단점을 배워보며 왜 현업에서 테스팅을 잘 하지 않는지 생각해보았다.
단위 테스트 (Unit Testing)
특정 모듈이 의도한 대로 잘 작동하는가를 테스트하는 것이다. 다음과 같은 경우에서 단위 테스트가 특히 요구된다.
- DB
- 스키마가 변경되는 경우
- 모델 클래스가 변경되는 경우
- Network
- 예측한 데이터가 제대로 들어오는지 확인
- 데이터 검증
- 예측한 데이터를 제대로 처리하고 있는지 확인
단위 테스트를 하나의 모듈(기능) 구현이 끝날 때마다 진행한다면, 그 프로젝트는 TDD(Test-Driven Development)를 추구하는 것이다. TDD는 안정성은 높아지나 개발 속도가 느려질 수 있다.
Mock
단위 테스트가 라이브 웹 서비스 또는 데이터베이스에서 데이터를 가져오는 클래스에 의존하는 경우, 테스트 속도가 느려지거나 예외 케이스 발생시 (ex. 서버 오류, 인터넷 연결 안됨) 테스트를 못하게 되는 문제가 발생한다. 이떄 Mock객체를 사용해 테스트하고싶은 모듈의 가짜 버전을 만들어 가짜를 테스트하면 문제를 해결할 수 있다. Mock을 할 때 Mockito라는 프레임워크가 자주 쓰인다.
해보면서 느낀점은 소규모 프로젝트에서는 main()에서 테스트할 수 있는 것을 굳이 Mock을 사용할 필요는 없는 것 같다. 위에서 언급한 것처럼 서버와 데이터베이스를 다루지 않는다면 테스트를 안 써도 되겠다고 생각했다.
결론
내가 생각하는 결론은 print찍어보거나 main에서 간단하게 테스트가 가능하다면 그 프로젝트는 TDD가 매우 비효율적일 것이다. 이런 경우에는 굳이 Mock을 활용해서 복잡하게 테스트 케이스를 짤 필요가 없다고 생각한다. 하지만, 복잡한 네트워크 통신이나 규모가 매우 큰 데이터베이스의 구조를 변경하는 등의 작업에서는 개발 중간중간 테스트를 하면서 진행하는 것이 좋겠다고 판단했다.
대규모 프로젝트에서는 중간중간 테스팅을 하지 않으면 후반부의 전체 테스트 (ex. Regression)에서 QA팀의 원망을 들을 수 있을것 같다... 이건 프로젝트 총책임자나 QA팀장이 정할 일 것이다.
