GUI를 단위 테스트하려면 어떻게해야합니까?

내 코드의 계산은 잘 테스트되었지만 GUI 코드가 너무 많기 때문에 전체 코드 범위가 원하는 것보다 낮습니다. 단위 테스트 GUI 코드에 대한 지침이 있습니까? 말이 되나요?

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

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

MVP 및 MVC와 같은 디자인은 일반적으로 실제 GUI에서 최대한 많은 로직을 추상화하려고합니다. 이것에 대해 매우 인기있는 기사는 Michael Feathers의 "The Humble Dialog Box" 입니다. 개인적으로 나는 UI에서 로직을 옮기려고 시도한 경험이 혼합되어 있습니다. 때로는 매우 잘 작동하고 때로는 가치보다 더 문제가 많았습니다. 그래도 내 전문 분야의 외부에 있습니다.

물론 대답은 MVC를 사용하고 최대한 많은 로직을 GUI 밖으로 옮기는 것입니다.

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

당신이 시도 할 수 UISpec4J은 스윙 기반의 자바 애플리케이션을위한 오픈 소스 기능 및 / 또는 단위 테스트 라이브러리입니다 ...

웹 기반 UI 테스트를 자동화하는 Selenium RC 가 있습니다 . 조치를 기록하고 재생합니다. 여전히 UI와의 상호 작용을 수행해야하므로 적용 범위에 도움이되지 않지만 자동화 된 빌드에 사용될 수 있습니다.

Swing GUI 어플리케이션 을 위해 오이 및 Swinger 를 사용하여 기능적 승인 테스트를 일반 영어로 작성할 수 있습니다. Swinger는 Netbeans의 Jemmy 라이브러리를 사용하여 앱을 구동합니다.

오이를 사용하면 다음과 같은 테스트를 작성할 수 있습니다.

 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!"

이 Swinger 비디오 데모 를보고 실제로 작동하는지 확인하십시오.

다음은 몇 가지 팁입니다.

GUI없이 컨트롤러를 테스트하고 코드를 테스트 할 수있는 방법으로 GUI (컨트롤러 및 모델 객체가 있음)에서 최대한 많은 코드를 제거하십시오.

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

테스트는 예술적인 형태입니다. 논리를 최대한 GUI를 제거해야한다는 데 동의합니다. 그런 다음 유닛 테스트에 집중할 수 있습니다. 다른 테스트와 마찬가지로 위험을 줄이는 것이 중요합니다. 항상 모든 것을 테스트 할 필요는 없지만 많은 경우 가장 좋은 방법은 다른 영역에서 다른 테스트를 중단하는 것입니다.

다른 질문은 실제로 UI 레이어에서 테스트하려는 것입니다. UI 테스트는 일반적으로 작성, 유지 보수에 시간이 더 걸리고 취성이 가장 높기 때문에 가장 비싼 테스트입니다. 선을 그리기 전에 좌표가 올바른지 논리를 테스트하면 구체적으로 무엇을 테스트하고 있습니까? 빨간색 선으로 그래프를 테스트하려면 그려집니다. 미리 설정된 좌표를 지정하고 특정 픽셀이 빨간색인지 빨간색인지 테스트 할 수 있습니까? 위의 비트 맵 비교 작업에서 제안했듯이 Selenium은 GUI를 과도하게 테스트하는 것이 아니라 UI를 만드는 데 도움이되는 로직을 테스트 한 다음 UI의 어느 부분이 깨지거나 의심 스러운지 집중하고 몇 가지 테스트에 중점을 둡니다. 그곳에.

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

귀하의 질문에서 수집 한 것은 GUI 동작을 자세히 테스트하는 자동화 된 방법을 찾고 있다는 것입니다. 예를 들어 커브가 실제로 올바르게 그려 지는지 테스트하는 것입니다.

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

옵션은 사용하는 플랫폼 / 툴킷 / 프레임 워크에 따라 다릅니다. 예를 들어 GUI 프레임 워크로 Qt를 사용하는 애플리케이션은 Squish를 사용하여 테스트를 자동화 할 수 있습니다. 테스트 결과를 한 번 확인하면 자동으로 실행되는 후속 테스트 결과와 확인 된 결과를 비교합니다.

Swing & Ajax를위한 Window Licker

업계 컨센서스와 마찬가지로 GUI 테스트에 대한 저의 접근 방식도 발전하고 있습니다. 그러나 몇 가지 핵심 기술이 등장하기 시작했다고 생각합니다.

상황에 따라 이러한 기술 중 하나 이상을 사용합니다 (예 : GUI의 종류, 구축해야하는 속도, 최종 사용자의 자격 등).

1. 수동 테스트. 코드 작업 중에는 항상 GUI를 실행하고 코드와 동기화되어 있는지 확인하십시오. 코드 작업과 실행중인 응용 프로그램간에 전환하면서 작업하는 파트를 수동으로 테스트하고 다시 테스트합니다. 중요한 작업을 완료 할 때마다 회귀가 없는지 확인하기 위해 전체 화면 또는 응용 프로그램 영역에 전체 테스트를 제공합니다.

2. 단위 테스트. 기능이나 작은 단위의 GUI 동작에 대한 테스트를 작성합니다. 예를 들어, 그래프는 '기본'색상을 기반으로 색상의 다른 음영을 계산해야 할 수 있습니다. 이 계산을 함수로 추출하여 단위 테스트를 작성할 수 있습니다. GUI (특히 재사용 가능한 로직)에서 이와 같은 로직을 검색하여보다 쉽게 ​​유닛 테스트 할 수있는 신중한 기능으로 추출 할 수 있습니다. 복잡한 동작도 이러한 방식으로 추출 및 테스트 할 수 있습니다. 예를 들어 마법사의 일련의 단계를 함수로 추출 할 수 있으며 단위 테스트를 통해 입력에 따라 올바른 단계가 반환되는지 확인할 수 있습니다.

3. 컴포넌트 탐색기. GUI를 구성하는 재사용 가능한 각 구성 요소를 표시하는 유일한 역할을하는 '탐색기'화면을 작성하십시오. 이 화면에서는 모든 구성 요소가 올바른 모양과 느낌을 가지고 있는지 시각적으로 확인할 수있는 빠르고 쉬운 방법을 제공합니다. 구성 요소 탐색기는 A) 각 구성 요소를 한 번만 확인하면되고 B) 구성 요소를보기 위해 응용 프로그램을 자세히 탐색 할 필요가 없기 때문에 전체 응용 프로그램을 수동으로 수행하는 것보다 효율적입니다. 즉시 확인하십시오.

4. 자동화 테스트. 화면이나 구성 요소와 상호 작용하여 마우스 클릭, 데이터 입력 등을 시뮬레이션하는 테스트를 작성하여 응용 프로그램이 이러한 조작을 올바르게 수행하는지 확인합니다. 다른 테스트에서 놓칠 수있는 잠재적 인 버그를 포착하기 위해 추가 백업 테스트로 유용 할 수 있습니다. 나는 깨지기 쉽고 / 또는 매우 중요한 GUI 부분에 대한 자동화 테스트를 예약하는 경향이 있습니다. 문제가 발생했을 때 가능한 한 빨리 알고 싶은 부분. 여기에는 깨지거나 중요한 메인 화면에 취약한 매우 복잡한 대화 형 구성 요소가 포함될 수 있습니다.

5. 차이 / 스냅 샷 테스트. 출력을 스크린 샷 또는 HTML 코드로 캡처하여 이전 출력과 비교하는 테스트를 작성합니다. 이렇게하면 출력이 변경 될 때마다 경고를받습니다. GUI의 시각적 측면이 복잡하거나 변경 될 수있는 경우 Diff 테스트가 유용 할 수 있습니다.이 경우 특정 변경이 GUI 전체에 미치는 영향에 대해 신속하고 시각적 인 피드백을 원합니다.

가능한 모든 종류의 테스트를 엄격하게 사용하는 대신 작업중인 종류에 따라 테스트 기술을 선택하고 선택하는 것을 선호합니다. 어떤 경우에는 간단한 함수를 추출하고 단위 테스트를 수행하지만 다른 경우에는 컴포넌트 탐색기 등에 컴포넌트를 추가합니다. 상황에 따라 다릅니다.

코드 범위가 매우 유용한 지표라는 것을 알지 못했지만 다른 사람들이 그것을 사용할 수도 있습니다.

첫 번째 조치는 버그의 수와 심각성이라고 생각합니다. 첫 번째 우선 순위는 아마도 올바르게 작동하는 응용 프로그램을 갖는 것입니다. 응용 프로그램이 올바르게 작동하면 버그가 적거나 없어야합니다. 버그가 많거나 심각한 경우 아마도 테스트 중이 아니거나 테스트가 효과적이지 않은 것입니다.

버그를 줄이는 것 외에도 성능, 유용성, 접근성, 유지 관리 성, 확장 성 등과 같은 다른 방법이 있습니다. 이는 어떤 종류의 응용 프로그램을 구축하고 있는지, 비즈니스, 최종 사용자 등에 따라 다릅니다.

이것은 모두 내 개인적인 경험과 연구뿐만 아니라 Ham Vocke의 UI Tests 에 대한 훌륭한 글을 기반으로합니다 .

내가 아는 것에서 이것은 상당히 복잡하고 언어에 달려 있습니다. 많은 언어가 GUI를 테스트하는 고유 한 방법을 가지고 있지만 GUI를 실제로 테스트 해야하는 경우 (모델 / GUI 상호 작용이 아닌) 종종 실제 사용자 클릭 버튼을 시뮬레이션합니다. 예를 들어, Eclipse에 사용 된 SWT 프레임 워크는 SWTBot을 제공 하고 JFCUnit 은 이미 언급했으며 Mozilla는 XUL에서이를 시뮬레이션하는 고유 한 방법을 가지고 있습니다 (그리고 블로그에서 읽은 내용에서이 테스트는 매우 취약한 것으로 보입니다).

때로는 스크린 샷을 찍고 픽셀 완벽 렌더링을 테스트해야합니다 (모질라가 올바르게 렌더링 된 페이지를 확인하기 위해이 작업을 수행한다고 생각합니다)-더 긴 설정이 필요하지만 그래프에 필요한 것일 수 있습니다. 이렇게하면 코드를 업데이트하고 테스트가 중단 될 때 이미지가 실제로 실패했는지 수동으로 확인하거나 그래프 렌더링 코드를 개선하여 더 멋진 그래프를 생성하고 스크린 샷을 업데이트해야합니다.

Swing을 사용하는 경우 FEST-Swing 은 GUI를 구동하고 어설 션을 테스트하는 데 유용합니다. "버튼 A를 클릭하면 대화 상자 B가 표시되어야합니다" 또는 "드롭 다운에서 옵션 2를 선택하면 모든 확인란의 선택이 취소 됩니다" 와 같은 것들을 테스트하는 것이 매우 간단합니다 .

언급 한 그래프 시나리오는 테스트하기 쉽지 않습니다. GUI 구성 요소를 만들고 표시하여 FEST를 사용하여 GUI 구성 요소에 대한 코드 적용 범위를 얻는 것은 매우 쉽습니다. 그러나 의미있는 어설 션을 만드는 것은 어려운 부분입니다. 의미있는 어설 션이없는 코드 적용 범위는 자기기만의 운동입니다. 그래프가 거꾸로 그려 지거나 너무 작지 않은지 어떻게 테스트합니까?

자동화 된 단위 테스트를 통해 GUI의 일부 측면을 효과적으로 테스트 할 수 없으며 다른 방법으로 테스트해야한다는 점을 받아 들여야한다고 생각합니다.

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