안드로이드 TDD, 안정된 개발 환경 구축

기존의 필자는 테스트라고 하면 해당 기능을 개발하고 나서 앱을 실행하여 해당 메서드의 결과를 보거나 로그나 디버깅을 통해 앱을 체크하는 UI 테스트의 형태로 개발을 하였습니다. 그러다 TDD라는 개발 방식을 알게 되었습니다.

 

TDD란 Test Driven Development의 약자로, ‘테스트 주도 개발’이라고 명합니다. 기존의 개발 프로세스가 디자인 → 개발 → 테스트 순서였다면, TDD는 개발에 앞서 테스트케이스를 작성하는 프로세스를 가집니다.

 

이게 어려운 말이 아닙니다.

실패가되는 테스트 케이스라는 게  실패가 되는 시나리오를 만드는 겁니다. 클래스나 인터페이스의 없는 함수를 호출하고 해당 함수의 결과를 테스트합니다. 이러한 테스트는 실패될 수밖에 없습니다.  그러니 이 함수나 기능이 성공할 수 있도록 기능을 구현합니다. 기능 구현후 테스트를 성공시키고 해당구현을 리팩토링을 거치고 이걸 반복하여 개발을 하는 것이 TDD의 흐름입니다. 이는 번거로울 수 있으나 ui 테스트를 거치기 전 유닛테스와 통합테스트를 통해 앱의 안정성을 높이고 버그를 줄여 탄탄한 앱을 만들게 됩니다.

 

Google Test Automation Conference 에서 제안된 테스트 피라미드이다. UI Testing은 10%, Integrating Testing은 20%, Unit Testing을 70%로 구현하는 것이 권장됩니다. 그만큼 UI Testing으로는 완벽하게 버그를 찾을수없습니다. 다른 테스트를 병행하면서 버그를 줄여나가야 됩니다.

 

그렇지만 모든기능에 이렇게 TDD를 수행하기에는 휴먼리소스가 많이 소모가 됩니다. 개발기간도 길어질 거고 그렇다고 테스트를 하지 않는다면 불안전한 앱이 되어 버립니다. 그래서 안드로이드문서에서는 자동화를 이용하여 휴먼리소스를 줄일수있다고 말합니다. 그 대표적인 방법이 Mockito 나 스텁, 테스트 더블을 활용하는 방법입니다.