Steps performed
1. Open a web page where data needs to be entered programmatically
2. Retrieved Element instance by passing element Id.
3. Call SetText function in Actions instance in ArtOfTest.WebAii.TestTemplates.BaseTest class by passing element and textToSet
Expected solution
Text need to be entered in the text box always.
Actual Output
Text is not always entered in the text box. Some times entering correctly and sometimes skipping it without entering the value. When debugging, observed that, the element instance is retrieved properly and SetText function is called and no exceptions are thrown. When the value is not entered, setting the control again at the top of the function and running it again will set the value in the text box.
Can any one tell me the reason for this weird behaviour?
Please let me know if more details are required.
Your description sounds like a timing problem. Since test scripts usually run very quickly it is easy for them to outrun your web application. If your test runs while debugging it (i.e. running slowly or single stepping) but intermittently fails when run at full speed, you are almost certainly running into a timing problem. Your web application may not be ready to accept text input at the time your test script is trying to feed the data into it, which is a very common problem if your web application is doing an AJAX postback. The easiest method to overcome such a problem is to add a fixed delay just before the SetText call. A more advanced technique is to monitor some property or element contained within your web application to detect when it's ready for input and wait for that to be set. Once that property is correctly set then call the SetText function.
Cody
Telerik Technical Support Team
Related
I have ASP.net webform that opens a popup window. example window.open(""); The POPUP window closes itself when a hyperlink is clicked inside. [Like search for person by name, select person and pass the person back to the parent form.] Then posts back from the javascript. When it is a full window[not a popup], It does not postback or close the window. When not recording for a test, it opens the modal popup and closes\posts back fine.
The real problem is you cannot finish a test if you cannot close the popup and transfer the selected values back to the parent form.
How do I stop the test recorder from opening the window in full screen. Or how can I make the popup perform normally[close and postback the data] when windowed.
Here is a little info. In the popup I force a postback after closing the window here.
function CancelPopupWindow() {
self.close();
//Here to force a post back on the parent. This is used to automatically save the data
window.opener.__doPostBack('', '');
}
Anyone else hating this problem. Please vote for a fix at User Voice.
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/16390135-make-web-performance-popup-javascript-dialogs-open
There is a workaround. The program Fiddler can be used to record the entire test then use Fiddler's menu => File => Export sessions => All sessions => Visual Studio web test and then follow the remaining prompts. That will produce a .webtest file. Like any other .webtest file it will probably need work to resolve dynamic data etc.
A variations is to record as much as you can with Visual Studio. From the start of the test up until the problem occurs. If possible you could also record the completion of the test. So just the piece with the problem is omitted. You can also record the problem part with Fiddler and save that. Now you have two or possible three .webtest files that cover the whole test. Now just merge them. With the Visual Studio web test editor you can copy requests and paste them into other tests. (Or else where in the same test. You can also drag requests in a .webtest to reorder them.
The purpose of recording the steps that use JavaScript is to learn enough of what they do so as to replicate enough of their action for the web test. So mixing pieces from different recordings is valid.
The .webtest file contains XML and so can be edited with a text editor. I often make changes in this way, for example to replace many occurrences of the same string with a context parameter. Editing at this text level can help when merging pieces from multiple files. Just be careful to make backups. Visual Studio just gives refuses to load .webtest files with mal-formed XML.
We are currently testing parts of our application that open in popup windows. These windows are subclasses of TitleWindow. The issue we now run into is that the popups seems to be registered multiple times and that tests are sometimes executed on popups that have already been closed (or so it seems).
I thought this had to do with the way we closed and removed our popups, but I can't really spot any problems there. After looking into the FlexMonkey source code, I saw that there is an explicit check for "TitleWindow" in the ADDED_TO_STAGE handler, after which the popup is added as an application window. But the popup never seems to be removed from the "_windows" collection. As a result, when you open the tree view in FlexMonkey, there are several instances of the same popup window class. This probably also explains why our tests sometimes do not seem to run (visually), but execute and verify correctly, as they are ran on a hidden instance of a popup. I would expect the MonkeyAutomationManager to also listen to REMOVED_FROM_STAGE events and remove the popup when it is closed.
Am I missing something here or is this an (known) issue?
My guess is that it isn't an issue, it's simply that your code isn't properly cleaning the object and removing it from the display list. You also need to remember that garbage collection does not run right after you remove something from the stage. It could be possible that your window, even if it has been removed from the stage is in fact still listening and responding to events.
Have a rather bizarre issue with Flex throwing an error when teh application is running in the background. I use Selenium and SeleniumFlexApi to run various tests against my app. If the browser window is in the foreground or any part of it is visible to teh screen, the test pass as expected. However, if the window is in the background and not visible, I am getting the following error in 1 part of my app.
ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller.
I have a VBOX that creates a number of children and then upon creationComplete(or UpdateComplete, I've tried both) it then needs to remove any of the children that are not visible. Each child has a listener for CreationComplete which checks if the child is visible and if not, adds it to an array which is iterated over when the parent UpdateComplete is fired. I cant seem to find any reason for this behavior and am curious if its an issue with the Flex Component LifeCycle.
The most recent version of the Flash Player (10.1) will automatically "slow down" when minimized. I think it drops to a couple of frames a minute [as opposed to the standard 24 per second for Flex]. I don't know specific number.s This is for performance and 'battery life' reasons.
If there is anything in your app, or in your testing, that requires specific timing or uses a timer, then this will easily break unit tests.
I've heard from other folks that this have other folks that have had issues with this. The best solution I've heard proposed is "Add a flag to turn this off; even if it's only in the debug player." But, there is no solution right now other than "run your tests w/o the app minimized"
Just wanting to know if anybody has seen an example of a telnet/chat or other console like FLEX application where you can use the same TextArea as input/ouput area.
I've been trying to modify the app at:
http://livedocs.adobe.com/flex/3/html/17_Networking_and_communications_8.html
but so far, computer says no.
All the implementations I've seen use a combination of TextInput and TextArea.
The challenge is that we'll be using this app to telnet into some old routers and we'll need to do a fair amount of copy/pasting. Based on what I've seen, it seems that I would need to point the mouse into the TextInput in order to be able to right click and paste, which is not very sleak.....
Your thoughts,
Fran
edit Just realized that I had trimmed out what was directly pertaining to the question: I was unable to find anything that used the TextArea for input and output; see the below suggestions if custom-component suggestions are ok.
The TextArea component only fires a change event whenever a user adds input. Whenever you set the text field programmatically, a change event does not fire--you could maybe use that as a way to know what is user input and console "responses" by looking for carriage-returns (\r).
I'm unsure if you have a requirement to maintain the user's input at the bottom-most line (like a console), even after the console responds with something like auto-complete. If that's the case, then something a bit more complex would have to come into play (such as remembering where the user's input started/ended) or the requirement of a single-component console needs to be reconsidered--sleek is nice, but not always necessary.
When I try to access the hidden TABs of my tab navigator control in action script, it returns a null error. But it works OK if I just activate the control in the user interface once. Obviously the control is not created until I use it. How do I make all the tabs automatically created by default ?
<mx:TabNavigator creationPolicy="all"/>
That should do it. Deferred instanciation is a feature, but sometimes it is a hassle.
The Flex framework is optimizing creation be default (creationPolicy="auto") so if you have a configuration dialog with a lot of tabs, for example, and the most useful tab is the first one, your application does not spend time and memory initializing the tabs that the user never sees.
This makes a lot of difference when dialogs like this never release, and is a good default to go with.
One thing to look at is using a private variable in your dialog/form instead of pushing the data to the control on the hidden page. This style treats the whole form as if it were a component, which it sort of is. To repeat: the MXML form/dialog/canvas is a class, and it can have data and methods in addition to containing other components.
Cheers
On a side note, I've run into the deferred-loading policy in a multi-state application, and circumvented it by forcing all elements to be included and invisible in the initial state. Something to consider, but only as a hack.