조금 더 개발에 집중하기 위한 테스트 자동화 검토

이 글은 제가 재직하는 회사에 테스트 자동화를 도입하는 과정을 작성한 글입니다.

현재 재직하는 회사의 앱은 회원제 서비스 앱으로 가입하는 방법에 따라 다양한 모드가 존재해 앱을 배포할때마다 모든 모드에 대한 테스트를 수행하는데 많은 시간이 걸렸고 또 제대로 테스트 했는지 확인하는 것도 어려웠습니다. 앱을 배포할 때마다 이런 비효율적인 시간을 없애기 위해 테스트 자동화를 도입하기로 결정하고 테스트 자동화에 대해 검토를 시작하였습니다.

 

이 글에서는 왜 테스트 자동화가 필요하고 테스트 자동화를 하기 위한 도구에는 어떤 것들이 있는지에 대해 설명합니다.

 

왜? 테스트 자동화가 필요한가!

개발자들이 특히 제가 제일 귀찮아 경시하게 되는 과정이 기능을 만들고 테스트하는 과정 입니다.

대부분 기능을 만들고 머리 속에서 생각나는대로 꾹꾹 테스트를 해보고 문제 없네! 오케이~~~ *^__^* 하고 빌드하고 배포하게 됩니다.

이런식으로 배포해 문제가 터져서 헬게이트를 겪으면 기능을 만든다음에 정신 차리고 열심히 테스트를 하게 됩니다.

하지만 주먹구구식으로 테스트를 하는 것은 한계가 있습니다.

서비스의 기능이 점점 많아지고 복잡해지고 개발할 것은 많고 시간은 없고, 저녁때 약속은 계속 있고, …

시간이 계속 흐르다보면 다시 테스트에 소홀해지고 계속 문제가 터지게 됩니다.

 

그럼 이제 문제의 심각성을 느끼고 책임을 전가할 대상을 찾게 됩니다. 문제를 해결할 대안으로 배포 전에 다같이 모여서 테스트 하는 시간을 갖자고 요구합니다.

이것도 처음에는 잘 지켜지지만 다같이 모여서 테스트하는 것에는 시간 & 공간적인 한계가 있어 대부분 2~3번 배포 후에 흐지부지됩니다.

 

그럼 다시 처음으로 돌아가고, 이 과정을 무한 반복하게 됩니다.

 

기능을 추가, 수정, 삭제 했다면 배포하기 전에 테스트하는 것은 필수적인 것 입니다.

 

하지만 테스트 중 대부분은 항상 반복되는 테스트인 것들이 많아 이런 것들만 자동화해도 많은 개발자에게 가중되는 테스트 부담을 대폭 줄 일 수 있습니다.

 

그리고 실동작하는 서비스를 눈으로만 테스트 함으로 명시적으로 에러가 나지 않는 한 데이터가 잘 못 표기 되는 것을 확인하기가 곤란한 경우가 많습니다.

테스트 자동화를 통해 이런 부분을 잡아 낼 수 있습니다.

 

테스트를 자동화 함으로 개발자는 배포 시마다 반복되는 기능 테스트의 압박에서 벗어날 수 있고 눈으로 확인하는 한계를 벗어날 수 있습니다.

 

테스트 자동화는 모든 문제를 완벽하게 수정한 다음에 배포 하는 것을 지원하지 못합니다.

하지만 테스트 자동화는 개발자가 조금 더 나은 서비스를 개발할 수 있도록 많은 것을 지원합니다.

• 매번 반복되는 테스트를 안해도 되고, 

• 눈으로 확인하기 힘든 데이터 확인이 가능하고,

• 배포 안정성이 확보되어 서비스 안정성이 높아짐.

 

어떤 것을 테스트할지 정하기!

테스트 자동화를 도입하기 전에 반드시! 꼭! 사전 검토해야 되는 것이 서비스의 어떤 부분을 테스트 자동화 할 것인지 구분하고 범위를 정해야 한다는 것 입니다.

테스트 자동화를 도입하는 것이 좋기는 하나 회사 및 서비스의 상황에 맞지 않는 테스트 자동화는 개발자의 부담만 가중 시키고 궁극적인 목적인 서비스 안정성에는 아무런 도움을 주지 못하고 개발 일정을 지연시키는 요인이 되기도 합니다.

 

예를 들어 설명하면 애자일 방식으로 서비스를 개발하는 팀에서 UI Test 도구인 “Espresso“ or “UI Automator”를 도입하게 되면 UI가 변경될 때마다 기존에 작성된 테스트 코드를 대폭 수정해야 되어 테스트 코드 수정에 개발만큼 많은 시간이 소모되게 됩니다.

 

물론, 그래도 서비스의 안정성이 확보되므로 괜찮다고 생각할 수 있으나 테스트  때문에 오히려 팀의 역량이 부족한 상황이 올 수 도 있습니다.

테스트는 팀의 역량이 받쳐주는 한 최대한 많이 자주하는 것이 좋지만 이러한 생각에 매몰되어 테스트에만 팀의 모든 역량을 투입하는 것은 잘 못된 생각 입니다.

 

그러므로 팀의 역량을 고려하여 테스트에 적당한 부분만 투자하는 것이 좋습니다.

위 예를 다시 들어 설명하면 애자일팀은 초기 UI가 변경이 많은 구간 개발에서는 Unit 테스트만 자동화를 진행하고 이후, UI 변경이 많지 않은 구간에서 상황에 따라 “Espresso“ or “UI Automator”를 도입하는 것이 좋습니다.

물론, 역량이 된다면 초기 개발부터 모두 도입하는 것이 좋습니다. (갑자기, 대기업 부럽… ㅠ_ㅠ)

 

테스트 자동화를 지원하는 라이브러리에는 어떤 것들이 있는가?

테스트 라이브러리은 크게 “Unit 테스트 라이브러리”와 “UI 테스트 라이브러리” 두가지로 구분할 수 있습니다.

 

Unit 테스트 라이브러리

Unit 테스트 라이브러리는 말 그대로 단위 테스트를 지원하는 라이브러리로 JUnit, Mockito, PowerMock 등이 있습니다.

 

UI 테스트 라이브러리

UI 테스트 라이브러리는 서비스의 UI에 데이터가 정상적으로 보여지고 동작하는지 테스트하는 라이브러리로 방식에 따라 화이트박스와 블랙박스 방식 그리고 멍청이 테스트 방식이 있습니다.

 

다음 절부터는 각 라이브러리들에 대해 자세히 설명하겠습니다.

 

JUnit (Unit 테스트)

JUnit은 보이지 않고 숨겨진 단위 테스트를 끌어내어 정형화시켜 단위 테스트를 쉽게 해주는 테스트용 라이브러리입니다. 

JDK 1.4에서 추가된 assert...를 사용하여 Test를 진행 할 수 있습니다.

JUnit은 테스트 결과를 단순한 텍스트로 남기는 것이 아니라 Test클래스로 남기므로  개발자에게 테스트 방법 및 클래스의 History를 넘겨줄 수도 있습니다.

특징은 아래와 같습니다.

• 단위 테스트 Framework 중 하나

• 문자 혹은 GUI 기반으로 실행

• 단정문으로 테스트 케이스의 수행 결과를 판별함(assertEquals(예상 값, 실제 값))

• 어노테이션으로 간결하게 지원함

• 결과는 성공(녹색), 실패(붉은색) 중 하나로 표시

 

Mockito (Unit 테스트)

Mockito는 JUnit 위에서 동작하며 Mocking과 Verification을 도와주는 라이브러리 입니다.

Unit 테스트를 위한 Mock 인스턴스를 생성해서 Mock 객체 동작을 지정하고 테스트 대상 로직이 제대로 수행 되었는지 확인이 가능합니다.

 

PowerMock (Unit 테스트)

Mockito와 마찬가지로 JUnit 위에서 동작하며 Mockito에서 지원하기 힘든 복잡한 코드 구조에서 Mock 객체 생성이 가능하도록 캡슐화 우회 메소드들을 지원합니다.

 

Espresso (UI Test)

화이트박스 방식의 테스트 라이브러리로 테스트 코드에서 직접 서비스의 액티비티를 직접 호출하고 레이아웃 구성 요소에 직접 접근이 가능해 다양한 테스트가 가능합니다.

레이아웃 구성요소가 바뀔 때마다 테스트 코드를 수정해야 한다는 단점이 있습니다.

 

UI Automator (UI Test)

블랙박스 방식의 테스트 라이브러리로 패키지 이름으로 서비스를 실행하고 화면 구성 요소로만 접근 가능해 시나리오 위주로만 테스트가 가능합니다.

제한된 테스트만 가능하지만 레이아웃 구성요소가 아무리 바뀌더라도 UI가 변경되지 않는다면 코드 변경 없이 테스트가 가능합니다.

 

Monkey (UI Test)

Android 지원하는 멍텅구리 방식의 테스트 프로그램으로 위에 언급한 테스트 라이브러리들과는 달리 랜덤하게 Event stream을 발생시키기 때문에 예측불허인 극단적인 상황도 테스트가 가능하며 “스트레스 테스트”가 가능합니다.

멍텅구리 방식이지만 스트크립트를 통해 제한적이나마 테스트 시나리오를 작성할 수 도 있으며 서비스의 Event 발생 빈도, 발생 주기, 발생 횟수 등을 사용자가 조절하여 Hunan resource를 낭비하지 않고도, 극단적인 상황을 쉽게 테스트가 가능합니다.

 

Appium (UI Test)

Appium은 네이티브, 모바일 웹 그리고 하이브리드 어플리케이션의 자동화를 해주는 오픈소스 툴입니다.

현재 iOS, Android 그리고 Windows Desktop 플랫폼을 지원하고 있으며 동일한 API를 이용해서 iOS, Android에 테스트를 실행이 가능합니다.

 

Cucumber (UI Test)

Cucumber는 BDD(Behavior Driven Development, 비지니스 중심) 기반의 개발 방법론에 입각하여 비지니스 레벨의 테스트 케이스를 생성하는 툴로 고객이 이해할 수 있는 논리적인 언어로 테스트 시나리오를 지정할 수 있습니다.

Ruby로 개발되었으나 현재는 Java와 Javascript를 포함한 다양한 언어를 지원합니다.

 

정리

테스트 자동화의 기반이되는 Unit 테스트를 JUnit 라이브러리를 중심으로 필요한 경우 Mokito, PowerMock을 사용하여 자동화하면 되지만 UI 테스트의 경우는 여러가지 상황을 고려해야 합니다.

Espresso와 UI Automator는 적은 학습 비용으로 테스트 자동화가 가능하다는 장점이 있지만 플랫폼에 종속적이라는 단점이 있고 Monkey 툴은 스트레스 테스트에는 좋지만 제대로 테스트하기에는 한계가 분명하며 Appium과 Cucumber는 멀티 플랫폼이라는 장점이 있지만 학습에 많은 비용이 들어간다는 단점이 있으므로 회사와 팀의 역량을 고려하여 상황에 맞는 UI 테스트를 선택하는 것이 좋습니다.

 

현재 우리 회사 상황을 고려해볼 때 Appium과 Cucumber는 배제하고 플랫폼(AOS, iOS)별로 테스트 라이브러리를 적용하느 것이 가장 좋아 보입니다.

Android는  Unit 테스트로는 JUnit(+ Mockito, PowerMock)를 도입하고  UI 테스트로는 Espresso를 적용하는 것이 좋아 보입니다.

 

Unit 테스트 모듈은 개발 순서는 아래가 적당할 듯 합니다.

• Network Unit

• 비지니스 Unit

• 리스트 Unit

• …

 

UI 테스트 모듈은 … (To be continue…)