Should GUIs have their own automated tests?

Is there any reason for automating tests that focus on GUI (and not to things under it)? In my opinion GUI (and changes in it) should always be tested by a real person.

What can you gain with the automated GUI focusing tests? My own experience has been 开发者_如何学JAVAthat GUI focusing tests almost always break because someone changed something for a really good reason. They seldom seem to find anything interesting.

This is a tough one. Automated testing tools and frameworks do a great job and are well worth the time and effort as long as the GUI does not change too much. The problem with automated testing is that it breaks down precisely when you need it the most: when the GUI is changing rapidly during a development cycle.

As a result, I have settled on a hybrid approach for the projects I lead and manage. I like to use manual testing on areas of the GUI that are changing rapidly during a development cycle. Once things are pretty stable, we do some sort of automated GUI testing (e.g. Selenium for web apps) that we put into the build process to guard against future regression. If at all possible, QA people write the automated tests. Sometimes developers have to pair with QA testers to do this when the automated tool is too code intensive.

This hybrid approach seems to work well as long as we are using good design practices that separate concerns properly so that unit tests can exercise all underlying logic properly. The one thing you must avoid is weaving application logic into the GUI layer.

It depends.

If your GUI is a relatively thin layer over your business logic and minor bugs in the GUI are not critical to your business then you might choose not to spend time testing your GUI thorougly with unit tests. That time could perhaps be better invested in testing more critical code.

If your GUI is very sophisticated and is a big selling point for your application then you may may wish to invest time in testing it both automatically and manually. Automatic testing doesn't completely replace manual testing, as you still need human testers to make sure that the GUI looks correct and that the interface is clear and intuitive.

See Wikipedia for more information about testing GUIs - for example by recording mouse and key input and replaying it. There is also a list of software that can aid you in creating GUI unit tests.

Depends on "what" part of the GUI you test. Do you test the behavior of the system by means of running a GUI test, or do you want to test if your GUI is displayed correctly at all times.

In the latter case it depends on your application. If layout and design is importang, I agree. However, if it is some app where the core functionality is not the layout itself, there is not point in investing time for testing layout. It would be better to write GUI test which test the functionality by using the GUI instead of some function calls. This way, real behavior is better simulated.

Humans are great at testing GUIs. They're expensive, though. Automated testing tools, theoretically at least, decrease the cost of testing UIs. If you release frequently, manual UI testing time can go through the roof really quickly.

I personally have never seen automated UI testing tools pay pack their setup costs, for the projects I've been on. Their tests tend to be brittle and don't react well to layout changes. For that reason, I'm hesitant to put much confidence in them. I'd be happy to be proven wrong, though.

That is possible. For the browser you have test suits like selenium, that interact with the browser.

My approach in this situation is usually to unit test non-GUI layers, use automated testing for the GUI as far as possible and then manually test anything that's left. I also use manual testing for ad-hoc defect detection to identify missing test cases.

For me, this provides the best ratio of test coverage to cost. Ultimately it depends on what you're trying to achieve - is this mission-critical software or a simple app where failure is purely an inconvenience?

You are better of letting usability test come first. Besides how are you going to test unit GUI? What would be the output? If somebody clicks something and gets what he "initially" was looking for? What should be considered an unaccepted behaviour ?

You will get tons of bullcrap to look through. Usability is a big word, but simple usability test is hiring a mate of yours(preferably not someone you know, a friend of a friend) who you might consider to be in application 'target audience'. Putting on a camtasia/camstudio (desktop recording software, might be good to record his face). Give him some tasks on a piece of paper(or in person, sometimes paper is better cause you wont be interfering - more lifelike scenrio). And watch what he is doing!

If he requires assist then you see sections of attention for future developement. Never try to influence the guy telling him stuff like "but look here is this button, I thought its more convinient this way".

You will get much better output of such test, rather than waste your time with computer-to-computer testing. GUI is an INTERFACE between human and computer. Unit testing gui is like trying to parse the book you have just written and seeing if its any good. Sure it will eliminate spellcheck errors for instance, but its a very small thing -> compared to book's real objectives.

Yes, of course GUis should have there own unit tests. See for example IcuTest.

The problem is that GUI testing is complicated. Once you have that solved, the world is yours.

If you have repetitive monotonous tasks in the GUI testing and need to do that for multiple combination of browsers and OS, automating the GUI is worth. With maintaining techniques, the famous question "UI changes will make automation irrelevant" can be answered.