In general how does one test a various parts of a GUI? What are good practices? (Yes I am being overly general here).
Let take for Notepad's Find dialog box:
What are some things that can be tested? How does one know its working correctly? What are edge cases to look out for? Stress tests?
I think it is better to separate out functional aspects and the usability aspects for the GUI testing.
Let us say in the above example take the use case of user entering some text and hitting the Find button. From the functional aspect I would say your tests should check whether this user action (event) calls the appropriate event handler methods. These can be automated if your code has good separation between the GUI display code and the
functional part.
Testing of usability aspect would involve checking things like whether the display occurs correctly in multiple platforms. I think this needs to be verified manually. But I think there are some tools that automate this kind of GUI testing as well but I've no experience with them.
Hey.
When someone asks for tests for GUI I always assume that that mean 'this part of application that is accessible via this GUI'. Otherwise it would mean testing the only the GUI without any logic hooked. Dunno why no one never actually asked for testing if the events are fired when button is pressed or is displayed window acquiring focus.
Anyway back to the question. First of all find out about equivalence classes, boundary conditions other testing techniques. Than try to apply it for given problem. Than try to be creative.
All those should be applied when creating following tests:
1) happy path tests - application acts right when given input is good
2) negative tests - application acts right when given input is bad
3) psychotic user behavior (I saw someone use this term, and I find it to be great) - that one user that has nothing better to do than break your application or is to stupid to actually know how bad and horrible things he is doing with your app.
After all this if all tests are passing and you can't figure out other, than you don't know is it working properly, but you can say that it passed all tests and it seems to be working correctly.
As for given GUI example.
1)
Is the application finding string that is in opened file?
Is the application finding character that is in opened file?
How is it reacting to reaching end of file during search?
Is it finding other appearances of given string/character or just one, when there are many of those appearances ?
Is it handling special search characters like * or ? correctly?
Is it searching in desired direction?
Is it 'Mach case ' option working properly?
When opening find setting some criteria, canceling search and launching it again - are search criteria back to default values? Or are they set as you left them when clicking Cancel?
2)
Is it informing user that no mach was found when trying to search for data that is not in opened file?
Is it reacting properly when trying to search down form end of file?
Is it reacting properly when trying to search up form beginning of file?
How search feature is reacting when no file is loaded? (in MS notepad it can be done, but in other editors you can launch editor without opening a file hence this test)
Can I mark both Up and Downs search direction?
3)
Is it working properly on 4GB file?
Can I load 4 GB string in 'Find What:' field and search for it?
Can I provide as input special characters by providing ASCII codes? (it was done like pressing Alt and number of character... or something like that)
Can I search for empty character (there was something like that in character table).
Can I search for characters like end of line or CarretReturn?
Will it search for characters form different languages? (Chinese, or other non-english alphabet characters)
Can I inject something like ') DROP ALL TABLES; (if that would be web based search).
Will I be able to launch proper event twice by really fast double click on search button? (easier on web apps)
With reasonable test suite you know it seems to work correctly.
It's difficult and error-prone to test finished UIs.
But if you are more interested form the programmer's perspective, please have a read of the paper The Humble Dialog. It presents an architecture for creating UIs whose functionality can be tested in code using standard testing frameworks.