- Posted by brunofig on January 8, 2008
After reading the Automated GUI testing - Is it worth it? from Mladen Prajdić I started thinking what I'm doing when I use the open source WaitN Web Application Testing tool to test my webforms. After a small debate with some colleagues I came to the conclusion that I can both unit test and use case test a UI.
In this post I will not cover any code, just explain my idea. If you want to see some code, please let me know.
So, lets "work" with the following example:
We have developed a funds transfer webform for a bank web application. This page has a custom server control for filling the account number. This control has the following business rules (applied using JavaScript, and validated on server-side):
- only numbers can be typed;
- a valid account number is validated using a specific formula;
- the control itself is a composite control containing the text box and a custom validator (for validating the typed account);
We also have a custom server control for the amount value. This control also only allows numbers and the "," digit for the decimal values.
There's also another custom server control that observes the state, in this case, of the account control, and when this is filled with a valid account number, enables the transfer button.
So we now have a webform with a destination account text box, a amount text box and a transfer button.
Now I came to realize that I can both Unit test and Use Case test the UI.
Unit Testing the UI
So, we have developed 3 custom server controls (account, amount and behavior). Although they are server controls, they have also a strong client-side usage, that can be tested. This said, We can build a web page only contains our account control, a validation summary and a asp.net button.
So using the WaitN Web Application Testing I can unit test the control on his web environment and test if all the client-side side business rules are ok.
WaitN allows me to fill the control with a value, calling all the client-side events, like the keypress and the keydown. It also allows me to access the DOM of my web page, accessing this way to all the html on my page. So I can, for instance, test if typing and invalid account number the custom validator is fired and the correct message is showed on the validation summary.
Use Case Tests on the UI
Use Case tests differs from the unit test in the way that what we are testing is not the functionality of the control, but what the customer accessing the page can do and what are the behaviors of our page according to this use. So, for instance, an returning to the Transfer page, we can use the WaitN tool to test if typing and invalid account still maintains the transfer button disabled. Other Use Case tests like if both account number and amount number are filled the transfer button becomes enabled, if the amount value is less than 0 a error message is showed, etc.
Conclusion
After all this babbling, I think that we can both Unit test and Use Case test our UI. What do you think?
