그냥 'TDD'와 'GWT'로 검색하면 this article으로 쉽게 연결되며 저자는 컨테이너없이 GWT 애플리케이션을 테스트하는 방법을 설명했습니다. 그러나 나는 그의 디자인이 모든 디자인을 먼저 가졌기 때문에 그의 예가 테스트 주도적이라고 생각하지 않는다. 그리고 나서 '테스트 우선'이 아니라 나중에 테스트를 작성한다.GWT 개발을 어떻게 테스트합니까?
GWT와 같은 UI에서 '테스트 우선'개발이 가능합니까? 어떤 사람들은 UI 코드가 TDD에 적합하지 않다고 말했다. 하지만 MVC 패턴을 채택하면 MC 부분을 적어도 테스트 할 수있을 것 같습니까? (그래서 V는 테스트 구동 방식으로 개발할 수없는 UI 부분이다).
기사 예제에서 처음으로 실패한 테스트는 무엇입니까?
시험 운전 UI는 화면에서 볼 때까지 화면에서 원하는 것을 알지 못하기 때문에 문제가됩니다. 이러한 이유 때문에 GUI 개발은 반복적으로 반복되는 경향이있어 테스트를 통해 운전하기가 어렵습니다.
이것은 우리가 GUI 용 TDD를 포기한다는 것을 의미하지 않습니다. 오히려 GUI에서 가능한 많은 코드를 푸시하여 간단한 배선 코드 만 남겨 둡니다. 이러한 배선은 문제의 본질에 영향을 미치지 않으면 서 우리가 필요로하는 반복적 인 대규모 변경을 가능하게합니다.
이 기술은 수년 전에 Michael Feathers가 "The Humble Dialog Box"이라는 제목의 기사에서 가장 잘 묘사 한 것 같습니다. 그것은 또한 4 년 전에 그런 저주를 일으킨 Model-View-Presenter 패턴의 근본적인 아이디어입니다. 이제 Passive View 및 감독 컨트롤러 패턴으로 분리되었습니다. 이 질문의 기사 링크는 이러한 아이디어를 활용하지만 테스트 중심 방식이 아닌 테스트 방식을 사용합니다.
아이디어는보기를 제외한 모든 것을 테스트하는 것입니다. 사실, 우리는 오랫동안 좋은 견해를 쓸 필요조차 없습니다. 실제로보기는 너무 어리석게 간단해서 아마 단위 테스트를 전혀 필요로하지 않을 것입니다. 그렇지 않으면 사실 마지막으로 기록 될 수 있습니다.
감독관을 테스트하려면 화면에 데이터를 표시하는 방법을 이해하기 만하면됩니다. 데이터가 어디에 있는지, 글꼴이 무엇인지, 색상이 무엇인지, GUI의 방대한 반복을 유발하는 기타 외관상의 문제가 무엇인지 알 필요가 없습니다. 오히려 한 데이터 항목이 일종의 텍스트 필드라는 것을 알고 있습니다. 다른 하나는 메뉴 일 것이고, 또 다른 하나는 버튼이나 체크 박스가 될 것입니다. 그런 다음보기에서이 항목을 올바르게 렌더링하기 위해 묻는 데 필요한 모든 질문을 요청할 수 있는지 확인합니다.
예를 들어 텍스트 상자에 기본값이있을 수 있습니다. 보기는 그것을 요구할 수 있어야합니다. 메뉴에는 회색으로 표시된 항목이있을 수 있습니다. 보기는이 정보를 요청할 수 있어야합니다. 보기에서 묻는 질문은 모두 프레젠테이션에 관한 것이며 비즈니스 규칙이 없습니다.
동일한 토큰으로, 어떤 것이 바뀌면 감독관에게 알려줄 것입니다. 컨트롤러는 모든 유형의 유효성 검사 및 오류 복구를 포함하여 데이터를 적절히 수정 한 다음 뷰에서 데이터를 표시하는 방법을 묻습니다.
이 모든 것은 시각적 디스플레이와 분리되어 있기 때문에 테스트 구동이 가능합니다. 모두 에 관한 것이므로 데이터가 조작되고 표시되며 이 아닌 것은입니다. 따라서 대규모 반복 작업이 필요하지 않습니다.
GUI를 통해 Swing 및 GWT 응용 프로그램의 개발을 성공적으로 테스트 주도했습니다.
"GUI 바로 뒤에있는"테스트는 모델 코드와 GUI 구성 요소 간의 통합을 무시합니다. 응용 프로그램은 모델이 변경 될 때 GUI에 데이터를 표시하고 GUI에서 입력을 받고 모델을 업데이트하기 위해 이벤트 핸들러를 연결해야합니다. 모든 이벤트 처리기가 올바르게 연결되었는지 테스트하는 것은 수동으로 수행하는 경우 매우 지루합니다.
GUI를 통해 테스트 할 때 극복해야 할 큰 문제는 개발 중에 GUI 변경 사항을 처리하는 방법입니다.
GWT에는이 문제를 해결하는 방법이 있습니다. GWT 위젯에 디버그 ID를 설정하고 DebugID 모듈을 애플리케이션으로 가져와야한다. 그런 다음 테스트는 웹 브라우저를 제어하고 ID로 요소를 찾아 클릭하거나 텍스트를 입력하여 응용 프로그램과 상호 작용할 수 있습니다. Web Driver은이를 수행하기위한 아주 좋은 API입니다.
그러나 시작일뿐입니다. 또한 GUI 구조에서 테스트를 분리해야합니다. 즉, 사용자가 UI를 탐색하여 작업을 완료하는 방법입니다. 이것은 GUI를 통해 테스트하든 GUI를 테스트하여 컨트롤러를 테스트하든 상관 없습니다. 컨트롤러에 대해 테스트하는 경우 컨트롤러는 사용자가 응용 프로그램의 다른보기를 탐색하는 방식을 지정하므로 테스트가 컨트롤러에 연결되어 있으므로 해당 탐색 구조에 테스트가 결합됩니다.
이 문제를 해결하기 위해이 테스트에서는 "드라이버"계층 구조를 통해 응용 프로그램을 제어합니다. 테스트는 로그인, 주문 입력 및 지불과 같은 사용자 중심 활동을 수행 할 수있는 드라이버와 상호 작용합니다. 드라이버는 GUI를 탐색하고 데이터를 입력하여 이러한 작업이 수행되는 방식에 대한 지식을 캡처합니다. 버튼을 클릭하거나 입력 필드에 텍스트를 입력하는 것과 같이 "제스처"로 탐색 및 데이터 입력을 수행하는 방법을 캡처하는 하위 수준의 드라이버를 사용하여이 작업을 수행합니다.
이 용어는 사용자 중심의 디자인 문헌에서 자주 사용되지만 다른 용어로도 사용됩니다.