When doing Acceptance Testings to the GUI, do tests to the GUI actually show the GUI (in a fraction of a second, I suppose) or are they just mock implementations? I’m talking about frameworks as WindowLicker, White, NUnitForms, etc.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When doing Acceptance Testings to the GUI, do tests to the GUI actually show the GUI (in a fraction of a second, I suppose) or are they just mock implementations? I’m talking about frameworks as WindowLicker, White, NUnitForms, etc.
I’m going to assume you mean automated testing. My interpretation of acceptance testing for a GUI involves people actually using the GUI to see if it does what it’s supposed to do, in which case you obviously need to show the GUI.
In the test cases I’ve written for GUI components you usually create a genuine UI without mockups, but don’t make it visible. Usually that is sufficient, and mockups of the higher level GUI components can be hard. However a lot of GUI components need to be part of a component tree to function This means that you generally need to run on a machine which has a display, even if you don’t use it. There are some functions where GUI components behave differently when they are visible, but I’ve been able to work round that, with a single exception involving JOGL.