2013-05-22 4 views
15

내 앱은 대다수의 정보를 얻기 위해 서버와 통신하는 대부분의 GUI입니다. 무엇인가 잘못되면 일반적으로 네트워크 호출이나 JSON 객체에 대한 잘못된 가정을합니다.유닛 테스트, 안드로이드 앱

단위 테스트는 이러한 네트워크 관련 작업 및 입출력 관련 작업에 적합하지 않습니다. 그렇지 않으면 단위 테스트라고 부르지 않습니다.

저는 제 경우에 단위 테스트의 요점을 수집하려고합니다. Android 버튼을 클릭 할 수 있는지 또는 EditText에서 입력 한 내용을 볼 수 있는지 테스트하는 이유는 무엇입니까? 난 그냥이 위의 방법은 내 모든 활동,에서 onCreate에서 실행 나는이 응용 프로그램의 작동을 알고있는 통과하면이 지루한 테스트

private void initElements(){ 
    placeButton = (Button) findViewById(R.id.currplace); 
    placeButton.setText(MainActivity.this.getString(R.string.findingLocation)); 
    placeButton.setEnabled(false); 
    selectplaceLayout = (LinearLayout)findViewById(R.id.selectplaceLayout); 
    selectplaceLayout.setVisibility(View.GONE); 
    splash = (RelativeLayout)findViewById(R.id.splashbg); 
    infoLayout = (LinearLayout)findViewById(R.id.infoLayout); 
} 

을 implementating의 유틸리티를 이해하지 않습니다. 이것에 대한 단위 테스트는 중복되는 시간 소모적 인 일입니다. jUnit 및 Android 테스팅 프레임 워크의 모든 메소드에 익숙하지 않아 시간이 많이 걸린다.

짧은 이야기가 짧습니다. 요점은 무엇입니까? 이 시험들에 대해 생각해야 할 특별한 방법이 있습니까? 필자가 지금까지 본 모든 예제와 튜토리얼은 간결성을 위해 가장 간단한 예제에 대해서만 이야기하지만, 주로 클라이언트 - 서버 애플리케이션에서 단위 테스트를 실제로 사용할 수는 없다.

내가 선언하고 초기화 한 것으로 알고있는 Android보기에 액세스하면 무엇을 발견 할 것으로 예상됩니까? 그래서, 통찰력

답변

19

귀하의 질문에면이 많이 있습니다 감사합니다 너무 제한 방법

이에 대해 생각해야하지만, 내 생각에 - 당신은 아마 당신의 프로젝트에 단위 테스트가 필요하지 않습니다.

프로젝트에 비즈니스 로직이 많이 필요할 때 단위 테스트가 정말 빛납니다. 이 경우 응용 프로그램을 여러 계층 (예 : 3 계층 구조)으로 나누어 비즈니스 논리 계층에 자연스러운 격리를 추가하고 단위 테스트의 안전망으로 다루는 것이 좋습니다.

안전망 비즈니스 레이어의 리팩터 중에 엉덩이를 덮는다. 그리고 그것은 단위 테스트의 주요한 것 중 하나이다. (TDD는 좋은 부가 효과를 줄 수있다.)

그러나 모든 유니콘과 무지개가 아니며 단위 테스트에 비용이 들며 때로는 많은 비용이 듭니다. 좋은 단위 테스트가 격리됩니다 (즉, 작은 코드 조각을 처리). 즉, 클래스를 테스트에 배치하려면 추상화 레이어를 추가해야합니다.

이것은 시스템 또는 부정적인 영향을 미칠 수 있습니다. 계층화는 복잡성이 증가하면서 시스템을보다 유연하게 만듭니다.

그런 말로하면 - 단위 테스트의 가치는 프로젝트에서 소개 할 추상 비즈니스 로직의 양에 비례합니다.. 아키텍처에 추상 레이어를 추가하는 것이 과잉이라면 단위 테스트를 추가하지 않아도됩니다. 아키텍처는 빌드를 현명하게 만듭니다.

설명에 따르면, 일반적인 앱은 외부 서버 측의 프레젠테이션 계층이되는 경향이 있습니다. 그것은 안드로이드 핸드셋에 대한 정보를 제공하는 것을 제외하고는 그다지 그다지하지 않으며 사용자의 행동을 주요 비즈니스 로직이 완료되는 서버 측의 명령으로 변환합니다 (제어).

이 접근법으로 작성한 대부분의 코드는 "이것을 표시하는 방법"및 "이 경우에 서버에 신호를 보내는 방법"과 관련됩니다. 이런 종류의 코드는 분명히 플랫폼에 크게 의존하고 있습니다. 따라서 테스트를 거치려면 안드로이드 전용 코드/동작을 많이 모방해야합니다.

이제 Android는 다소 구체적인 플랫폼입니다. 이는 성능 최적화가 가능하고 개발자가 신속하게 앱을 시작하고 제작할 수 있도록 설계되었습니다. 이것은 종종 "swiss-knife"클래스를 사용하는 것을 의미하며, 일반적으로이 클래스를 조롱하면 실제 지옥이 될 수 있습니다. 물론 모의 광고를 유용하게 사용하려면 플랫폼이 어떻게 작동하는지 이해해야합니다. 즉, 이러한 테스트를 수행하는 데 필요한 오버 헤드가 높아지게됩니다.

프레젠테이션 계층을 테스트 할 때 또 다른 문제는 비즈니스 계층보다 훨씬 동적으로 변경되는 경향이 있다는 것입니다. 물론, 이것은 당신이 당신의 리팩터링을해야만 더 많은 오버 헤드가 추가되는 테스트를 의미합니다.

다양한 유틸리티/도우미 클래스에 대해 한 가지만 말해야합니다. 이러한 클래스가 프레젠테이션 레이어에 속하고 Android 코드에 종속되지만 다소 단순한 논리를 사용하더라도 () 단위 테스트를 모의하고 작성하는 것이 쉽습니다. 실제로 이렇게하는 것이 좋습니다. 그러나 이러한 코드가 많다면 아키텍처/계층화를 잘 설계하지 못했고 현재하고있는 일에 대해 다시 생각해 봐야한다는 신호 일 수 있습니다. 결국

먼저이 질문에 대답해야 할 질문에 대답 :

이 응용 프로그램의 플랫폼에서 분리 추상화 레이어를 추가하기 위해 과도 설계 (overdesign) 될 것이다 (그것은 것입니다 귀하의 경우처럼 보인다) ? 그렇다면 단위 테스트를 사용하지 마십시오. 속도가 느려집니다. 그렇지 않다면 사용하십시오.

리팩터링을 많이 하시겠습니까? 코드가 많고 유지 보수가 많은 대규모 프로젝트 인 경우 레이어링 및 단위 테스트에 투자 할 가능성이 높습니다 (단, 한 눈에 볼 수는 없습니다). 그것이 당신의 경우가 아니라면 - 단위 테스트에 신경 쓰지 말고 빨리 가십시오.

단위 테스트를 작성하려면 플랫폼을 많이 조롱해야합니까? 예 (귀하의 경우 인 것 같습니다) - 단원 테스트를 작성하지 마십시오 - 노력할 가치가 없습니다.

희망이 도움이 될 것입니다.