I need in some way to automate tests of validators. My tested application is .NET GUI one. For instance some fields validates if any forbidden characters are not entered, length of entered strings, strings with only white spaces etc. I'm quite confused because I have limited time to automate it. Normally I use Test Complete and I know that automate such things is effortness. I guessed that since GUI code responsible for validations is changed very rarely I can perform some static code validations using i.e. Perl or any other interpreted language (check if in some placed in code proper methods are invoked or sth).
Any ideas how to automate it quickly?
If you are planning on using the Black box method then almost any type of GUI automation tool will work for you. Input data and look for acceptance or error messages. Very simple once you understand how to use the tool. There will most likely be a learning curve involved while you learn to manipulate the tool, so don't plan on completing your project next week.
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~
Thanks. I rather tring to find the simplest and quickest way to perform such testing (don't matter whether black or white box). Testing tool for GUI automation I know the best is Test Complete. But I'm not sure if it is the best way to perform such testing.
If you're already familiar with TC.. then just use TC and create a data driven test.
Write a generic keyword of function that will take in the parameters and the expected result, then use a spreadsheet where you can easily list the parameters and their corresponding results and feed it to the test.
In this case agree with David. Go what you are familiar with' and a data driven approach using TC might be best in this immediate situation
When doing testing the UI elements you are typically testing 2 things.
- The properties of UI elements themselves (e.g. IME enabled, maxLength, right to left, and casing)
- The event handlers which sit between the UI layer and the functional layer and which typically do a lot of input validation.
It is relatively easy to get the UI properties of each control using reflection and verify the settings. WRT event handlers it is generally better to test each event handler by itself. This could actually save you some testing. For example, if you have 5 input textboxes on a form and they all take the same type of data (all calling the same event handler) if you check the properties are identical for each textbox control and test the event handler similar to how you might test an API, then what is the increased value of throwing the same set of tests against each of the 5 textbox controls through the form. (Note...I would still test through the form, but probably a subset of those
tests, and focus my testing on scenario or end-2-end.)
Also you are quite right and in my experience form properties and event handlers rarely change (unless there is a bug) during the couse of a product lifecycle. Which is another reason why you might want to thoroughly test the event handler using an API testing approach, flush out those problems early, and then sequence through a variety of sanity checks via user scenarios or regression tests during the SDLC.