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.
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.