Unit testing UI application

Can a UI application be unit tested? Lets consider a UI application which has a simple login form. What开发者_如何学Python would form part of unit test for this UI application. Should the backend response validation form part of unit test for login form?

In my opinion, It should include;

1. appropriate rendering of UI components in the form.
2. enabling/Disabling of components based on user actions (password can not be empty message when password is not entered and form is submitted).

Are there any guidelines/rule of thumbs which should be used while devising unit test cases for UI application? Should an application behavior considered in unit testing?

In general, testing UI components is not an easy task - you need a good architecture on the tested code, quite some tools (which may come with some license costs...), and at least one virtual machine.

The most important part is to have some 'Model-View-younameit' architecture in place, because only this allows you to isolate the UI stuff from the rest of the application. A test for the login form can then be as follows:

• A tool (e.g. White or Ranorex) mimics a user typing in some user/password combination.
• The test verifies (by the help of e.g. a mocking framework or Typemock), that the correct methods are called (or not called under certain circumstances).

What you have to avoid for UI testing in any case is calling some business logic underneath. If you can't isolate the UI this way (which is often the case especially for legacy projects...), then automating UI testing may not be beneficial at all, because it often comes with way too much effort in such a situation. Sometimes you better go with manual testing...

HTH!
Thomas

UI testing is not unit testing in the strict sense, however there are tools/frameworks to help that. I assume you mean a web UI - for this you can try e.g. Selenium or HttpUnit.

Note that "appropriate rendering of UI components" is a very loose term - it can mean things which can not be verified automatically, only by human eye.

Testing functionality via the UI is always more cumbersome than testing the code directly via classic unit tests. Hence it is always recommended to separate the business logic from the UI as much as possible - then you can thoroughly test all the nooks and crannies of the logic itself via unit tests, and need only integration tests on the UI to verify that the app as a whole works as expected.

In your example, ideally the input validation and the authentication would be separated from the GUI, so you could unit test these (preferably by mocking out the DB). Thus you could verify that the login works as expected for all sorts of normal/abnormal inputs (empty userid/password, strange characters, very long input, logging in the same user twice, ...). Then in the UI tests you need only test a few common test cases to verify that the app indeed is functional.

If your UI is a native graphical application, you may want to consider AutoIt (Windows only), which allows you to programmatically click any place on the screen and simulate text typed into an widget or just keyboard presses. It also has the ability to read the color of pixels at specified positions. Or you can use it to take screen shots and do an image comparison.

If it's web based, you may also want to consider using xpath to determine (non-graphically) whether elements exist in your generated HTML. It doesn't help you with how pages are rendered though. AutoIt may help with that as well, but you won't be able to perform the same type of test on a different platform, assuming you would like all users from all platforms to be able to reasonably access your page.

If your UI is console based, consider using Expect. I prefer the Perl based expect, which is based on the TCL Expect.

I know I'm not answering directly about rules or guidelines, but I think knowing what tools are available out there will open up the possibilities that you think may not exist or had not considered. Just as an example, you can use AutoIt to determine whether a component is disabled or enabled because usually the widget is of a different color from the enabled version when it is disabled. So by using AutoIt to obtain the color of a pixel or region of the screen, you can programmatically test whether that widget is enabled or not.