문제

내 코드의 계산은 잘 알려져 있지만 GUI 코드가 너무 많기 때문에 전체 코드 커버리지가 원하는 것보다 낮습니다. 단위 테스트 GUI 코드에 대한 지침이 있습니까? 심지어 의미가 있습니까?

예를 들어 내 앱에 그래프가 있습니다. 그래프 테스트를 자동화하는 방법을 알 수 없었습니다. 그래프가 올바른지 확인하려면 인간의 눈이 필요합니다.

(저는 Java Swing을 사용하고 있습니다)

도움이 되었습니까?

해결책

MVP 및 MVC와 같은 디자인은 일반적으로 가능한 한 실제 GUI에서 많은 논리를 추상화하려고합니다. 이것에 대한 매우 인기있는 기사 중 하나입니다 "겸손한 대화 상자" Michael Feathers. 개인적으로 저는 UI에서 논리를 옮기려고 노력하는 경험이 혼합되어있었습니다. 때로는 매우 잘 작동했으며 다른 경우에는 가치보다 더 어려웠습니다. 그래도 내 전문 분야를 벗어납니다.

다른 팁

물론, 대답은 MVC를 사용하고 가능한 한 GUI에서 많은 논리를 옮기는 것입니다.

즉, SGI가 OpenGL을 새 하드웨어로 포팅 할 때 화면에 원시적 인 세트를 그리는 한 번의 프레임 버퍼의 MD5 합을 계산할 수있는 단위 테스트가 많이 있었다고 동료로부터 소식을 들었습니다. 그런 다음이 값은 알려진 좋은 해시 값과 비교하여 API가 픽셀 정확한 지 여부를 신속하게 결정할 수 있습니다.

당신은 시도 할 수 있습니다 uispec4j 스윙 기반 Java 응용 프로그램을위한 오픈 소스 기능 및/또는 단위 테스트 라이브러리입니다 ...

다음은 몇 가지 팁입니다.

GUI에서 할 수있는 가장 많은 코드 (컨트롤러 및 모델 객체)를 제거하면 GUI없이 테스트 할 수 있습니다.

그래픽의 경우 그래픽을 생성하는 코드에 제공하는 값을 테스트해야합니다.

당신은 사용할 수 있습니다 오이 그리고 스윙 어 스윙 GUI 응용 프로그램을위한 일반 영어로 기능 수락 테스트를 작성합니다. Swinger는 NetBeans의 Jemmy Library를 사용하여 후드 아래에 앱을 운전합니다.

오이는 다음과 같은 테스트를 쓸 수 있습니다.

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

이것을 살펴보십시오 스윙 어 비디오 데모 실제로 볼 수 있습니다.

거기 있습니다 셀레늄 RC, 웹 기반 UI 테스트를 자동화합니다. 그것은 행동을 기록하고 그것을 재생할 것입니다. 여전히 UI와의 상호 작용을 통해 걸어야하므로 커버리지에 도움이되지 않지만 자동화 된 빌드에 사용할 수 있습니다.

테스트는 예술 형식입니다. 나는 논리를 가능한 한 많은 GUI를 제거해야한다는 데 동의합니다. 그런 다음 장치 테스트에 집중할 수 있습니다. 다른 테스트는 위험을 줄이는 것입니다. 당신은 항상 모든 것을 테스트 할 필요는 없지만 가장 많은 시간은 다른 영역에서 다른 테스트를 깨는 것입니다.

다른 질문은 UI 계층에서 실제로 테스트하려는 것입니다. UI 테스트는 가장 비싼 테스트입니다. 일반적으로 생성, 유지 관리하는 데 시간이 더 걸리며 가장 부서지기 때문입니다. 라인을 그리기 전에 좌표가 정확하다는 것을 알기 위해 논리를 테스트하는 경우 구체적으로 무엇을 테스트하고 있습니까? 빨간색 선으로 그래프를 테스트하려면 그려집니다. 미리 정해진 좌표를 설정하고 특정 픽셀이 빨간색인지 빨간색인지 테스트 할 수 있습니까? 위에서 제안한 바와 같이 비트 맵 비교는 작동하지만 셀레늄이지만 저의 주요 초점은 GUI를 과도하게 테스트하는 것이 아니라 UI를 만드는 데 도움이되는 논리를 테스트 한 다음 UI의 부분이 어떤 부분을 차단하거나 의심하고 소수의 테스트에 집중하는 데 집중하는 것입니다. 거기.

당신이 사용할 수있는 JFCUNIT GUI를 테스트하려면 그래픽이 더 어려울 수 있습니다. GUI의 스냅 샷을 몇 차례 찍은 후 자동으로 이전 버전과 비교했습니다. 이것은 실제 테스트를 제공하지 않지만 자동 빌드가 예상 출력을 생성하지 않으면 경고합니다.

내가 당신의 질문에서 수집 한 것은 당신이 당신의 GUI 동작을 자세히 테스트하는 자동화 된 방법을 찾고 있다는 것입니다. 당신이주는 예는 곡선이 실제로 올바르게 그려져 있는지 테스트하는 것입니다.

단위 테스트 프레임 워크는 자동화 된 테스트를 수행 할 수있는 방법을 제공하지만, 여러분이 원하는 테스트의 종류는 GUI 툴킷/라이브러리의 클래스가 여러 클래스의 올바른 동작을 확인하는 복잡한 통합 테스트라고 생각합니다. 테스트하고 싶지 않아야합니다.

옵션은 사용하는 플랫폼/툴킷/프레임 워크에 따라 크게 의존합니다. 예를 들어 GUI 프레임 워크로 QT를 사용하는 응용 프로그램은 Squish를 사용하여 테스트를 자동화 할 수 있습니다. 테스트 결과를 한 번 확인하고 후속 자동 실행 된 테스트는 결과를 확인 된 결과와 비교합니다.

창 licker Swing & Ajax의 경우

내가 아는 바에 따르면, 이것은 매우 복잡하고 실제로 언어에 따라 다릅니다. 많은 언어가 GUI를 테스트하는 방법을 가지고 있지만 실제로 GUI를 테스트 해야하는 경우 (모델/GUI 상호 작용과 달리) 종종해야합니다. 실제 사용자 클릭 버튼을 시뮬레이션합니다. 예를 들어, Eclipse에 사용되는 SWT 프레임 워크가 제공합니다. SWTBOT, JFCUNIT 이미 언급 된 Mozilla는 XUL에서 이것을 시뮬레이션하는 자체 방법을 가지고 있습니다 (블로그에서 읽은 내용 에서이 테스트는 매우 부서지기 쉬운 것 같습니다).

때로는 스크린 샷을 찍고 Pixel -Perfect 렌더링을 테스트해야합니다 (Mozilla는 올바르게 렌더링 된 페이지를 확인하기 위해이 작업을 수행한다고 생각합니다) - 더 긴 설정이 필요하지만 그래프에 필요한 것일 수 있습니다. 이렇게하면 코드를 업데이트하고 테스트 브레이크를 업데이트 할 때 실패가 실제 인 경우 이미지를 수동으로 확인해야하거나 그래프 렌더링 코드를 개선하여 더 예쁜 그래프를 생성하고 스크린 샷을 업데이트해야합니다.

스윙을 사용하는 경우 페스트 스윙 GUI를 운전하고 어설 션을 테스트하는 데 유용합니다. 그것은 같은 것을 테스트하는 것이 매우 간단합니다 "버튼 A를 클릭하면 대화 B가 표시되어야합니다." 또는 "드롭 다운에서 옵션 2를 선택하면 모든 확인란이 선택 해제되어야합니다.".

언급 한 그래프 시나리오는 테스트하기가 쉽지 않습니다. GUI 구성 요소를 작성하고 표시하는 것만 (그리고 아마도 Fest와 함께 운전 함)에 대한 코드 커버리지를 얻는 것은 매우 쉽습니다. 그러나 의미있는 주장을 만드는 것은 어려운 부분입니다 (그리고 의미있는 주장이없는 코드 범위는 자기기만의 운동입니다). 그래프가 거꾸로 또는 너무 작지 않았 음을 어떻게 테스트합니까?

자동화 된 단위 테스트를 통해 GUI의 일부 측면을 효과적으로 테스트 할 수 없으며 다른 방식으로 테스트해야한다고 인정해야한다고 생각합니다.

GUI 라이브러리를 테스트하는 것은 당신의 일이 아닙니다. 따라서 실제로 화면에 그려진 내용을 확인하고 대신 위젯의 속성을 확인하여 도서관을 정확하게 나타내는 것을 신뢰하여 위젯의 속성을 확인하는 책임을 피할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top