Unit Testing User Interface. What is an effective way ?

Question

I have an accounting & payroll client/server application where there are several input form with complex data validation rules. I am finding an effective way to perform unit testing of user interface.

For complex validation rules I mean:

• "Disable button X if I Insert a value in textfield Y"
• "Enable a combobox if I insert a value in a textfield" ...... ......

Most promising pattern i have found is suggested by M. Fowler (http://martinfowler.com/eaaDev/ModelViewPresenter.html).

Have you any experience about Unit Testing of User Interface? As technology stack I am using: .NET 3.5 & Windows Forms Widget Library.

Answer 1

Unit testing is not so good for testing an interface, by definition. Unit testing should test the back-end functionality of a single entity. For functional testing, get a framework for doing so. Consider things like Mercury (now HP) Quality Center or Performance Center. If you're on a budget, try Selenium.

Functional tests are a step up from unit tests, and shouldn't be confused with eachother.

Answer 2

User interface testing is hard and generally best done at a higher testing level than unit testing.

Testing controllers and logic using the MVC/MVP separation suggested by Martin Fowler is an excellent start, but you often need to augment this with automation tools like WinRunner or QTP to fully test the UI in an automated way.

Answer 3

I wouldn't call it "unit testing" exactly, but I have had some degree of success with running automated tests against a WinForms UI, and also in web UI using WatiN.

Assuming that you can get a handle to the window of the application you want to test, you should be able to script out a lot of C# code for testing the functionality of the user interface.

Many people condemn the idea of trying to run automated tests against a UI, because there is so much that that you can't test that way. For example, no automated test is going to notice that a font is ugly or some text is confusing or a button is slightly off-center. There is no question, for these types of things you definitely need an intelligent human person looking at the screen.

However, that type of testing aside, there definitely is a large array of repetitive testing that can be automated and performed regularly. Most large applications have a whole batch of regression test scripts that must be performed manually whenever a new release is going to go out the door. These tests are usually something you could train a monkey to do, just a list of instructions to click this link, enter some text, click this button, check the resulting message, etc. These things are awful waste of your QA tester's time, and makes them miserable, so if they can be automated away, great. These types of tests should be able to be run automatically by your build server every day, and could be crafted to be far more thorough than any manual testing.

Again, it won't find weird unexpecting things, but it will give you a certain level of confidence that your small change didn't break some other screen that you never heard of on the other side of the application.

Granted, this results in more ongoing work for the developers, because small changes to the application could break the tests for stupid reasons, just like any automated testing, but it should save you a ton of time in testing and debugging. Whether this is worth it for you is for you to decide, but I think it is a consideration that should not be dismissed as quickly as you normally see.

Answer 4

For complex validation rules I mean:

* "Disable button X if I Insert a value in textfield Y"

These rules test both Model and View, and that's what makes them tough. Instead, validate that when you insert a value in textfield Y, the model acquires that value; that a model with empty Y has X_ENABLED == false, and with non-empty Y has X_ENABLED == true; and that, given a model with X_ENABLED == true, the View's button is enabled. Only two of these tests involve the UI, and they should be so simple that they pretty much can't fail. Put the complex logic into the model where it is easily tested.

Answer 5

Untit testing the UI is, as others have said, a pain. I'd just like to add that Team Foundation 2010's new Test & Lab Manager feature is a great way to do both manual testing of UI and automating subsequent tests. It's smart enough to recognize GUI structures when running the tests, at least for WinForms, WPF, and websites.