예를 들어 오픈 소스 프로젝트 JChemPaint에서 GUI는 몇 가지 개별 테스트를 각각 몇 개의 Java 파일로 수집하여 FEST 프레임 워크를 사용하여 테스트합니다. 애플릿은 파일 당 한 번만 시작되고 체인에서 여러 독립적 인 테스트가 수행됩니다.매번 GUI 테스트를 연결하거나 애플릿을 새로 시작해야합니까?
나는 이것이 좋은 연습인지 알고 싶습니다. 물론, 매번 시작할 때 시간이 걸릴 것입니다. 그러나 이전 작업의 부작용 및 가능한 예외가 있음을 알 수 있지만 전문가는 아닙니다. 그래서 하나의 애플릿 시작에 여러 테스트를 넣는 것이 좋은 습관입니까?
(I 힌트 그럼에도 불구하고 환영합니다, GUI 테스트를위한 모범 사례의 수집도 찾고 있어요하지만 이러한 질문을 제기 할 수 없다.)나는이 두 top-level containers 사이의 어색한 부문 별 고민 해요 :
org.openscience.jchempaint.application.JChemPaint org.openscience.jchempaint.applet.JChemPaintAbstractApplet.
대담한 읽기 후에, 나는 비판적이되기를 꺼립니다. 내용을 다시 고려하면 필요한 중복 테스트의 양이 제한 될 수 있습니다. 매우 단순화 된 example에서 공통 초기화는 initContainer() 메소드로 제한됩니다. 비교해 보면 JChemPaint은 상당히 복잡하며 많은 양의 애플릿 매개 변수를 제공하며 정확한 전송을 테스트해야합니다.
이러한 리 팩토링은 계속 될 수 있습니다. appletests은 이전 개발 단계에서부터 최신 날짜로 표시되며 최신 jchempaint.src.test 아티팩트는보다 최신의 주석 기반 테스트 아키텍처를 반영하는 것으로 보입니다.
시간을내어 주셔서 감사합니다. 내가 아직도 명확하지 않은 점은 이것에 대해 FEST가 정말로 필요하다는 것인가? 내가 발견 한 대부분의 버그는 애플릿 논리에 있지만 GUI (스윙 등) 자체에는 없습니다. 또한 GUI의 버튼 동작을 이동하는 등 외모가 변경되면 FEST 테스트가 중단되며 필자는 가치가있는 것보다 많은 작업을 만드는 절차가 마음에 들지 않습니다. – rwst
나는 당신이 말하는 것을 보았다고 생각합니다. 이상적으로, 버튼은 그것이 최상위 레벨 컨테이너가 사용되는 함수가 아닌 컨테이너를 감싸는 컨텍스트에서 테스트됩니다. 반대로 애플릿은 매개 변수가 그대로 도착하는지 테스트해야합니다. – trashgod
Linux에서 FEST와 관련하여 몇 가지 문제가 있으므로 테스트를 위해 awt.Robot을 사용하려고합니다. – rwst
* "이전 작업의 부작용 및 가능한 예외가있는 문제를 볼 수 있습니다."* 해당 작업의 조합을 성공적으로 수행하면 완벽하게 이해할 수 있습니다. –
그럼, 문서가 모두 좋은 것입니다. – rwst