This question is locked. New answers and comments are not allowed.
I've created a test to Boundary Test a series of fields on a Page, by entering a value in one field and clicking the save button. Now the web page acts slightly different in serveral cases:-
- If the data is in the boundaries it just saves the page.
- If the data is below the lower boundary it displays a Dialog Box with a message.
- If the data is above the upper boundary it displays a Dialog Box with a different message.
Currently I have recorded entering a value and clicking Save. Now if I data-drive this recording, it will work whenever the data is valid (lower boundary; lower boundary + 1; mid boundary; upper boundary - 1; upper boundary) - when no dialog is displayed.
But how should I cope with the two cases (lower boundary - 1 and upper boundary + 1), WITHOUT going to Code Behind (which is not an option for us).
Thank you for your help.
- If the data is in the boundaries it just saves the page.
- If the data is below the lower boundary it displays a Dialog Box with a message.
- If the data is above the upper boundary it displays a Dialog Box with a different message.
Currently I have recorded entering a value and clicking Save. Now if I data-drive this recording, it will work whenever the data is valid (lower boundary; lower boundary + 1; mid boundary; upper boundary - 1; upper boundary) - when no dialog is displayed.
But how should I cope with the two cases (lower boundary - 1 and upper boundary + 1), WITHOUT going to Code Behind (which is not an option for us).
Thank you for your help.
1 Answer, 1 is accepted
0
Hello Mark,
In tests where you are expecting some of the data rows to make the web page react normally and some of the data rows to cause errors on the web page, code behind is your only option. There is no conditional type branching in WebUI Test Studio.
What you can do instead is separate your two (or three or four) testing scenarios into separate tests. Have one test in which you expect all the data rows to not generate errors. Have another test in which all the data rows should generate error code type 1. Have yet another test in which all the data rows generate error code type 2, etc.
One advantage to this approach is that you separate your individual test cases into individual test scripts which can be run independently on and as needed bases rather than having to go through every single row just to verify error type 1 is generated at the right time.
If you're interested in this approach, we recommend watching this video on Telerik TV. Should you have other questions, please let us know.
Best wishes,
Cody
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
In tests where you are expecting some of the data rows to make the web page react normally and some of the data rows to cause errors on the web page, code behind is your only option. There is no conditional type branching in WebUI Test Studio.
What you can do instead is separate your two (or three or four) testing scenarios into separate tests. Have one test in which you expect all the data rows to not generate errors. Have another test in which all the data rows should generate error code type 1. Have yet another test in which all the data rows generate error code type 2, etc.
One advantage to this approach is that you separate your individual test cases into individual test scripts which can be run independently on and as needed bases rather than having to go through every single row just to verify error type 1 is generated at the right time.
If you're interested in this approach, we recommend watching this video on Telerik TV. Should you have other questions, please let us know.
Best wishes,
Cody
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.