Develop Reference

how do i work around 429 errors in selenium?

I run into 429 errors a lot in selenium, because the driver is too fast for the server. this causes the website to get stuck (with no error message presented to the user). I use waits and I've tried using the sleep method but it doesn't always work. Is there anything I can do or is this a design flaw on the website - shouldn't the error be presented to the user so I can try to reload the page?
I am using incognito mode so cookies aren't an issue.

try adding the bellow line of code after declaring the driver
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
also using sleep having assigned it a fair amount of time? make sure that it's using millescondes
thread.sleep(3000);

It might be an issue that has to be handled in the source code of the application. I would do the following:
Run a performance test and see if I can replicate it.
Check the logs of the application to see if this happening frequently on production.
Please see following article for dev to handle 429 errors --> link
Otherwise the solution provided by #hamza belatra should be sufficient.
Unless it is a problem in your Test Architecture code, how to the driver is handled and so on.

restart java.exe from an applet

I have an applet packaged with a third part dll (from JTwain). My applet scans documents from the TWAIN compatible default printer. The applet fails on a paper jam and won't recover. The user navigates away from the page and the applet is destroyed. When returning to the page it fails again. Closing the browser (which kills java.exe process on the pc), and then returning to the page clears the problem and everything works.
I want to restart everything without requiring users to close down the browser. I've added a GUID query string to the URL's from which the applets resources are loaded - so I know nothing is being cached. I've checked in the windows task manager and there is no process created by the dll, it's all happening within the main java.exe process. I tried wrapping the scanning process in a thread so I could interrupt it in the stop or destroy methods (just in case the applets thread weren't stopped when the applet was destroyed), but that didn't work.
Any suggest would be greatly appreciated. Ideally I'd like some way to restart java when the applet unloads (but I doubt that's possible).
UPDATE
I've spent a couple of days trying to identify what causes the applet to fail. I still don't know :(
When the paper jam occurs something (not my code), is producing a couple of popups. The first alerts the user of the jam, and can be closed by clicking the OK button. The second says 'reading from device' and hangs. It cannot be close with the red, close window, icon in the top corner - I kill it from the task manager and windows asks to send a report regarding the 'non-responsive program'. I assume these popups are produced by the dll. And given that the second hangs, my assumption is that a thread started by the dll has hung while retaining a lock on some component of the TWAIN application. I get
com.asprise.util.jtwain.JTwainException: Failed to open the specified data source:
Source: TW-Brother MFC-9970CDW LAN Thrown
..when I try to access the scanner.
I'm at a bit of a loss as to how I can get more information. I'm testing my applet on a windows virtual pc (so as to use ie7), and don't have a method for step debugging in this environment. (And it's crashing on third party code for which I have no source anyway)

I see only two practical options here:
Use an API that handles paper jam without problems. Of course, that is easy to say (get robust API), harder to find.
Launch the app. free floating using Java Web Start. If it freezes up, the user can kill it and click the link for another instance in a new JVM. Or the applet might also call BasicService.showDocument(URLof.jnlp) if it can detect a problem with the DLL and is not itself frozen.
Of course, you should also report the bug to the ..Asprise(?) developers. The optimal solution would be to have the problem fixed at its source. Anything we do here is a 'workaround'.

Jenkins like Build Status Report Page?

Kinda a random question, but our company uses Jenkins
http://jenkins-ci.org/
Anyways there is a section for our company thats like a "Weather Report" in table form of build statuses. Basically It'll have a Weather Icon (Sunny/Cloudy/Thunderstorm) then on mouseover it'll tell what % of methods have been covered, and how many builds have failed (like 2/256) or something.
Also there is a Blue Glowing Indicator that well.....flashes/glows when a Project is being 'built' and turns solid blue when it is completed......Anyways How exactly is this done?
Obviously the webpage is some basic Html/Javascript and im pretty sure XML (for the tables). stuff, but....Im confused at how exactly you'd get the status of builds like they do, (especially checking what % of methods are completed?). And what about checking if something is currently being "built" or is completed (i'd imagine it returns some "SUCCESS" string.....when it's finished, but what about when it's being currently build....
Any ideas at how this is done? (and b4 someone asks "Why don't you ask the company") i'd rather just figure out how the basics are done to implement it myself in a test website.
I would take a screenshot....but im pretty sure most of stuff is considered confidential....and I wouldn't wanna get fired lol. But TL;DR How would you make your OWN build status checker.
EDIT: http://wiki.jenkins-ci.org/display/JENKINS/Firefox+Add-on+Build+Monitor
^^ thats a example of a firefox addon that sorta does what Im looking for, but I would want to create my own and not use jenkins( which is awesome, but I just want to figure out how they did it)

Javascript in the status page.
The simple version would use a call back to run every X number of seconds to request status information from the server with something like http://api.jquery.com/jQuery.ajax/, and then update the page accordingly.
A more advanced version, which avoids the need to poll every X seconds, would use something like Comet http://en.wikipedia.org/wiki/Comet_(programming)) which would allow the browser to keep a connection open, and for the server to send updates as they occurred.
The percent completion in Jenkins is just basically a guess based on how long the current build has been running vs how long recent builds took to complete, so assuming your server side tracks the length of tasks, you could take an average, and compare the length of the current run to calculate the percentage complete.

If you want to know how Jenkins/Hudson works, a good start is probably their Architecture Documents that were posted in January:
Hudson Web/REST Architecture
Hudson View Architecture
Hudson Execution Architecture
Hudson Remote Execution Architecture
Hudson Security Architecture
Hudson Plugin Architecture
If you want to look into how a simple continuous integration server works, you'd probably want to look at
the source of travis-ci or
the source of CI Joe
which are both simplistic and written in Ruby.
As for the live status indicator thingy with jenkins, equip yourself with Firebug and have a look around on the status page. You should see a bunch of Ajax requests going on.
For the build progress estimation part (I think that's what you mean by "checking what % of methods are completed", not?) I observed that Jenkins is just guessing that by relating time spent on this build / time spent on last run of this build.

Selenium RC and Internet Explorer

I am trying to create a fully-automated test suite for a web application, using Selenium RC and test cases written in Java. However, I have encountered a few problems that I have not been able to solve. Please let me know if you have a suggestion about any of these issues.
Single window mode. I would like to run single window mode because I think it will provide a significant performance improvement, and probably solve problem 2. I am able to run my test cases in single window mode with Firefox and everything works as expected, with much faster execution. However, I have not been able to get my test cases to execute when using single window mode with Internet Explorer; button clicks do not work at all, so the tests fail due to the browser never advancing to the next screen. The exact same test case executes fine in multi-window Internet Explorer. Is there some kind of trick I can use to get this working?
When running in multi-window mode, if there is an error in the test, or if the user exits the Selenium GUI window, the browser never closes. I know that it is possible to get the process id and kill it, but this seems rather dangerous, especially if the user is running multiple instances of the browser. This is part of the reason that I would like to use single window mode, if possible. Is there some other way, possibly by handling the window close event for the Selenium GUI, to solve this?
I am unable to use the waitForPageToLoad command in any of my test scripts because it will never recognize that the page has loaded and resume execution. I think this is because the pages use Javascript, but I am not sure; I don't have too much experience in webpage development. Right now, I am using the wait command and specifying the amount of time to wait. However, this is very unreliable, sometimes if the Internet connection is slow, my tests fail because the wait times are not long enough. Other times the tests are excessively slow, due to long wait times. Any ideas for how to handle this problem?
Thank you! I appreciate any answers or suggestions you can give. Please let me know if you would like some more information.

For multi widow close issue, you need to handle the exceptions. Call the close function in the finally block will resolve the window close issue.
For Page refresh, you need to check that manually and call in correct places. Usually clicking on links will cause page refresh before showing next screen.

Have you tried IE HTA mode? When I used to mess with this stuff it was the only reliable way to run tests on IE.
Not sure
You need to use the wait class. In essence you make an action then poll on an element which isn't present yet but you know will be when its safe to continue with the test. So you only ever wait the minimum time needed.

How would I debug this IE7 issue?

Problem:
Obscure error message http://img66.imageshack.us/img66/6746/confusedg.png
Conditions:
IE7, SP2, latest flash/java. Only reproducible on one machine.
Observations:
Smaller than a javascript alert box, and seems to be generated when a swf on my web page loads. The dialog is modal, however, like an alert box.
Issues:
I've tried matching the configuration of the machine in question, but a recreation of the machine does not get this error. I'm not ultra-familiar with flash/flex, so is there something that flex/flash could do which would cause this error dialog to appear.
How would one even go about debugging this? It's mostly not reproducible aside from a single machine, and the circumstances which cause the error are unknown. Thoughts?

Looks like a windows dialog to me. Neither Flash/Flex or Javascript. (though one could make either look like that if they tried).
The problem could be entirely machine dependent, it could be a virus, or it could be anti-virus or add blocker thinking the flash file is a threat. My automatic backup.recovery software sometimes pops alerts like that when it's in the middle of making a backup and I download something.
I'm meandering, my point is there are far more variables than just the browser and flash versions that could be coming in to play. I know that probably doesn't help much, but hopefully I've given you a few more ideas of what to check.

When you're setting up the "mirror" of your development machine, are you sure you're installing the version of Flash with Debugging enabled?
That might have something to do with it.

Have you tried using IE developer toolbar? http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en

Process Explorer would help debug this by displaying the call stacks of the IE7 process. You could then look at each call stack in order to find the one displaying the message box. This will show you exactly which modules are on the stack at the time the message box is displayed.