I was wondering if anyone new how to make the Automation Script in CodedUI wait for the web page to load before continuing on with the script.
So I fill out a form and press the "Continue" button, then the script times out because it gives up waiting. I realise I could use Playback.wait but then I would have code this each time I click continue.... and I have hundreds of scripts! Something similar to Seleniums WaitforBrowserLoad but for CodedUI
C# CodedUI in VS 2012
Any help would be appreciated.
In my experience, Coded UI is excellent about waiting for page loads to be complete before continuing test execution. That said, you can force a wait for a specific control to exist with WaitForControlExist method. This method is a member of the base class of all UI controls, UITestControl.
You could also use:
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
Sounds like your issue could be fixed if you create a settings file and increase the timeout.
Directions Here: Specifying Test Settings in Visual Studio
You could also call the WaitForControlReady method on the browser window object.
ex:
_browserWindow.WaitForControlReady(60000); //Should wait for 1 min
Related
I am new to coded UI, is it good practice to initialize Browser Window in each method of test case. For example i have two methods in my test case, I am trying to find control in each method, for that i write browser window in each method, can i write like that.
I don't see an issue with that approach.
Are you trying to reduce code/setup statements?
It really depends, you could have a test class with many test methods. however have a method attributed with ClassInitialize to launch the browser one time (and set the option to not destroy the window after each test) and keep reusing the same window. Then, possibly, have a method to close the window attributed with ClassCleanup.
Then in a test, you should only potentially need to use the NavigateTo method at the start of your tests to be on the right page.
Do you have test requirements dealing with sessions or saved data?
You may need to actively close down a window after a test and programmatically empty caches. Then in this aspect, I would be using BrowserWindow.Launch typically and letting CodedUi automatically destroy the window if i forgot to call close on the window.
I have my javascript file case_Javascript.js and it have a function poupulate javascript.
I have call this function on OnLoad of case entity.
I have used an alert("script runing") in the start of the js file. Only first time the alert() is shown. And its not runing then. I have to reset iis and publish each time to run this and it wont run again. I am stuck. Any Solution to get around?
This could be the settings of your IE.
IE >Tools > Internet Options > General Tab > Browsing History Settings >
Check for newer version of stored pages > Option "Never" radio button is checked or not
Set this to "Automatically".
i m new to MS Coded UI Automating, my Question is.
When i launch my Browser (IE) and fill the detials and then click on submit button. it takes me to new page where i get an error called action cannot be perform on hidden objects
i am using MS 2012 Premium Verison
thanks
Limited information to go on, but have you checked out this the fallowing?
http://blogs.msdn.com/b/visualstudioalm/archive/2013/09/17/coded-ui-mtm-issues-on-internet-explorer-with-kb2870699.aspx
Coded UI error: The following element is not longer availabe
This might be the annoying side effect of Windows Update KB2870699, update 4 for VS2012 is supposed to fix this but an alternative work around is simply to uninstall this update.
Is there any way of showing Wait Screen, while some processing is done in backend, using LWUIT in J2ME ? if yes then how if no then is there any alternate ?
You can look at progress bar with LWUIT. Sample Wait screen used in the makeover demo and the browser demo application in current LWUIT Repository. Also see here.
I had this issue as well, but got a workaround: these suggestions here seemed not to be the best for me. The dialog when it displays will block any other action except it is discarded, even if it was created with no commands.
What I did was to add a wait screen to the BorderLayout.CENTER of the main container or the Form, then when the thread running my background task finishes, the component is now replaced with the loaded component.
I dont know if anyone would find this useful since this has already been answered. I just felt like posting my own trick.
You can start a thread in which you do your stuff of getting data and all and in the UI thread show the loading dialog and then dispose that loading dialog once you are done with your services call.
i have a legacy massive vb6 editor with plenty of 3rd party libraries and controls and recently there is a need to set it up to make it multi thread so i can run a few other forms independently from the main editor form. Basically there's minimum communication between these other forms and the main editor except for running the other forms on a click of a button from the main page.
So from a lot of googling i found a method which converts the current app into a multi threading one by setting it up as an activex exe and adding a class set to global-multi-use to allow this to happen. Now while doing editing and testing via debugging mode, i found that when i exit a lot of weird crash will happen sometimes.
'main.frm - button click call
'On the button click, create a new object
Set obj = CreateObject("MyApp.clsThread")
Call obj.NewThread
'clsThread
' Create a new form and load it to run on a new thread
Public Sub NewThread()
Dim frm As Object
Set frm = New frmDogbert
Load frmDogbert
frm.show
Set frm = Nothing
End Sub
So what do i absolutely must know when i do this,i.e. potential problems,etc?, as i'm fearing that the app seems to be getting more unstable. Or is there a better way to do this?
Updates:
Instead of forcefully hacking my app into a pseudo multithreading app, i've taken the advice from the good people here and refactor out the component into standard exe and reverted back my app to a standard exe and call them via shell. Works beautifully :)
Thanks
Visual Basic 6 is not multi threading in of itself. The difference in the multi-tasking behavior between a ActiveX EXE and a ActiveX DLL is only apparent when referenced from another VB6 EXE. Objects instantiated from a Global Multi-Use Class defined in a ActiveX EXE run in their own context. Object instantiated from a ActiveX DLL are run in the context of the calling EXE.
Now multi-threading can be hacked into VB6 but it is very touchy and has a lot of don't (for example you can't use the stop button in the IDE to stop a debugging session or the program will crash).
What a ActiveX EXE is good is for spawning a separate but related instance that can run separately without halting the main program. Based on your brief description I would say your best best is to keep your EXE as is but more the forms/modules/classes to a separate EXE and have the original EXE reference the ActiveX EXE.
Note that you don't have to compile down to .EXE you can change the extension to .DLL and it is still a activeX EXE. You do this so that the user doesn't mistakely run the ActiveX EXE by itself.
Can you clarify the question a bit? I don't understand why it needs to be multi-threaded? Why can't you just display the forms non-modal, then they will all be visible and responsive at the same time. Unless you have some background processing operating all the time in your main form, which sounds unlikely from your question as it would lock up the main form as well as the others.
Melaos says: Well the main editor frm is the main thing here and I need to allow the user to run additional forms to do some other stuff like uploading things to our server and convert video files to other formats. And these forms use shell to call other exes. And the running time takes quite a while.
In that case I recommend making the other forms into separate EXEs rather than use multithreading, which is difficult. You say there's little communication from the main form to the subforms - it just shows them. Therefore you don't even need to make the subforms ActiveX EXEs. Just make them standard EXEs and shell them from the main form.