자동화 된 UI 테스트 도구를 사용해야하는데 Robotium과 Google Espresso를 사용하는 것이 혼동됩니다.
둘의 주요 차이점은 무엇입니까? 하나에는 있지만 다른 하나에는없는 기능이 있습니까?
자동화 된 UI 테스트 도구를 사용해야하는데 Robotium과 Google Espresso를 사용하는 것이 혼동됩니다.
둘의 주요 차이점은 무엇입니까? 하나에는 있지만 다른 하나에는없는 기능이 있습니까?
답변:
전체 공개 : 저는 Espresso의 저자 중 한 명입니다.
Espresso와 Robotium은 모두 계측 기반 프레임 워크입니다. 즉, Android 계측 을 사용 하여 테스트중인 활동을 검사하고 상호 작용합니다.
Google에서는 재고 계측보다 편리했기 때문에 Robotium을 사용하기 시작했습니다 (Robotium 개발자가 그렇게 만드는 것을 싫어함). 그러나 개발자가 신뢰할 수있는 테스트를 쉽게 작성할 수있는 프레임 워크에 대한 우리의 요구를 충족시키지 못했습니다 .
Robotium보다 Espresso의 주요 발전 :
동기화. 기본적으로 계측 테스트 논리는 UI 작업 (UI 스레드에서 처리됨)과 다른 (계측) 스레드에서 실행됩니다. 테스트 작업을 UI 업데이트와 동기화하지 않으면 테스트가 불안정 해지기 쉽습니다. 즉, 타이밍 문제로 인해 무작위로 실패합니다. 대부분의 테스트 작성자는이 사실을 무시하고 일부는 절전 / 재시도 메커니즘을 추가하고 더 정교한 스레드 안전 코드를 구현하는 사람은 더 적습니다. 이들 중 어느 것도 이상적이지 않습니다. Espresso는 테스트 작업 및 어설 션을 테스트중인 애플리케이션의 UI와 원활하게 동기화하여 스레드 안전성을 관리합니다. Robotium은이 문제를 수면 / 재시도 메커니즘으로 해결하려고합니다. 이는 신뢰할 수 없을뿐만 아니라 테스트가 필요 이상으로 느리게 실행되도록합니다.
API. Espresso에는 사용자 지정이 가능한 작고 잘 정의되고 예측 가능한 API가 있습니다. 표준 hamcrest 매처를 사용하여 UI 요소를 찾는 방법을 프레임 워크에 지시 한 다음 대상 요소에서 작업을 수행하거나 어설 션을 확인하도록 지시합니다. 이를 테스트 작성자가 30 개 이상의 클릭 방법 중에서 선택해야하는 Robotium의 API와 대조 할 수 있습니다. 또한 Robotium은 getCurrentActivity (어쨌든 current가 무엇을 의미합니까?) 및 getView와 같은 위험한 메서드를 노출하여 주 스레드 외부의 개체에서 작업 할 수 있습니다 (위의 요점 참조).
실패 정보를 지 웁니다. Espresso는 오류 발생시 풍부한 디버깅 정보를 제공하기 위해 노력합니다. 또한 고유 한 오류 처리기를 사용하여 Espresso에서 오류를 처리하는 방식을 사용자 지정할 수 있습니다. 나는 한동안 그것을 시도하지 않았지만 이전 버전의 Robotium은 일관성없는 오류 처리로 어려움을 겪었습니다 (예 : clickOnView 메서드는 SecurityExceptions를 삼킬 것입니다).
이전 답변과 달리 Espresso는 사용자 수가 많은 모든 API 버전에서 지원됩니다 ( http://developer.android.com/about/dashboards/index.html 참조 ). 일부 이전 버전에서 작동하지만 테스트는 리소스 낭비입니다. 테스트에 대해 말하면 ... Espresso는 포괄적 인 테스트 모음 (95 % 이상 적용)과 Google에서 개발 한 대부분의 Android 애플리케이션을 통해 모든 변경 사항에 대해 테스트됩니다.
Espresso는 Robotium보다 훨씬 빠르지 만 일부 SDK 버전에서만 작동합니다.
따라서 모든 장치에서 작동하는 테스트를 원한다면 Roboitum으로 이동하십시오. 그렇지 않다면 에스프레소를 마시고, 당신은 여전히 얼마 동안 베타 테스터가 될 것임을 잊지 마십시오.